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TECHNICAL  REPORT  ON  MANUAL 
INFORMATION  STORAGE  AND  RETRIEVAL  SYSTEMS 


The  Civil  Engineering  Laboratory  (CEL)  of  the  Naval  Construction 
Battalion  Center,  Port  Huenerae,  California,  has  identified  the  need  for  a 
data  management  system  capable  of  enhancing  CEL  Research,  Development,  Test 
and  Evaluation  (RDT§E)  activities  in  physical  security.  Previous  work  in 
this  field  undertaken  for  CEL*  was  directed  toward  a  preliminary  definition 
of  an  information  storage  and  retrieval  system,  as  well  as  the  preparation 
of  an  indexing  thesaurus  for  implementation  of  the  selected  system.  Work 
completed  included  a  review  of  candidate  manual  information  storage  and 
retrieval  systems  and  the  identification  of  a  manual  system  to  suit  the 
needs  of  CEL  and  its  user  community.  As  part  of  its  work  for  CEL,  Mission 
Research  Corporation  (MR C)  has  reviewed  this  work  and  further  examined 
manual  information  storage  and  retrieval  systems.  Three  manual  systems 
were  identified  and  examined  to  determine  their  compatibility  with  the 
current  CEL  needs.  Accordingly,  this  report  is  divided  into  the  following 
areas:  a  brief  discussion  on  indexing;  details  on  how  the  candidate  systems 
work,  including  their  capabilities  and  limitations;  and  recommendations  on 
the  selection  and  implementation  of  a  manual  system. 


information  Storage  5  Retrieval  System  for  Physical  Security  R0T$E  Program, 
N62583/75  M  X162,  Dataflow  Systems,  Inc.,  January  6,  197S. 

Indexing  Thesaurus,  Dataflow  Systems,  Inc.,  June  13,  1975. 
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BACKPROUND  INFORMATION 


Terminology 

The  design  and  activation  of  an  information  storage  and  retrieval 
system  necessitates  that  documents  be  indexed  by  subject  under  index  terms 
or  descriptors.  A  complete  set  of  index  terms  make  up  the  index  language. 
The  CEL  Indexing  Thesaurus  uses  each  entry  as  an  index  term;  the  thesaurus 
itself  constitutes  the  index  language.  Heirarchy  Terras  (HT)  are  used  to 
organize  the  index  terms  into  subgroups. 

Once  the  index  language  has  been  determined,  documents  must  be 
read  and  assigned  index  terms.  The  number  of  index  terms  assigned  to 
each  document  is  determined  according  to  the  needs  of  the  user.  To 
ensure  consistency  among  indexers,  however,  it  is  important  that  the  index 
terras  are  decided  upon  before  the  indexing  procedure  begins.  This 
controlled  list  of  index  terms  is  generally  referred  to  as  controlled 
vocabulary  or  authority  list. 

Pre-  and  Post-Coordination 

The  index  language  of  any  given  subject  should  include  the  capa¬ 
bility  to  express  the  subject  matter  of  documents  in  varying  degrees  of 
complexity.  Generally,  manual  systems  can  use  two  different  approaches 
to  develop  a  system  vocabulary  for  indexing  and  retrieving  documents. 

They  are  referred  to  as  pre-  and  post-coordination. 

For  CEL  purposes,  use  of  a  pre-coordinated  system  is  questionable. 
This  system  creates  index  terms  which  uniquely  identify  very  specific  topics. 
It  includes  labels  identifying  specific  classes  or  categories  that  are  the 
logical  product  of  more  than  one  class.  This  is  done  by  assembling  all  the 
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components,  or  as  many  as  possible,  under  one  subject  heading  before  index¬ 
ing.  A  typical  example  of  this  system  is  a  library  card  catalog.  Documents 
are  listed  according  to  their  subject  matter,  and  described  in  the  greatest 
detail  possible. 

An  example  of  an  index  term  formed  through  pre-coordination  is 
"audible  door  alarms."  Using  this  as  an  index  term,  one  uniquely  identi¬ 
fies  the  product  of  three  separate  classes;  doors,  alarms  and  audible. 

Pre- coordination  attempts  to  render  each  heading  as  specific  as  possible, 
although  this  is  not  always  achieved.  One  may  lose  valuable  information 
by  not  knowning  exactly  what  subject  heading  to  use  for  a  search. 

The  post-coordinated  approach  defines  only  relatively  basic 

classes  when  developing  index  terms.  The  best  way  to  make  the  distinction 

between  the  two  systems  is  that  post -coordination  uses  one  index  term  for 

each  concept,  whereas  pre-coordination  uses  one  or  more  concepts  in  each 

subject  heading.  In  other  words,  to  use  pre -coordinated  index  terms  to 

search  for  a  document  dealing  with  audible  door  alarms,  one  would  cross- 

index  the  descriptors  "doors,"  "alarms,"  and  "audible."  When  searching, 

one  can  use  some  or  all  of  the  descriptors  (index  terms).  Post -coordination, 

therefore,  allows  for  greater  flexibility  since  search  terminology  is 

developed  to  suit  the  specific  needs  of  the  searcher. 

* 

Item  and  Term  Entry 


Using  post -coordinated  index  terms,  search  cards  can  be  organized 
in  two  ways.  They  are  item  entry  and  term  entry.  When  using  item  entry, 
basic  information  about  each  document  is  contained  on  the  cards  used  to 
search  with.  Document  information  can  include  title,  author,  abstract, 
etc.  Term  entry  refers  to  searching  procedures  where  only  the  referen^ 
number  (accession  number)  of  the  document  is  identified.  The  searcl>6^N 
must  then  go  to  the  document  itself  or  some  secondary  cataloging 


system-  TO  ffmf  docuucnt  informat  iem.  Thntr tBau!|K*t  mti  uthuj,  ire- 
further  explained  in  the  following  discussion  of  the  three  candidate 
manual  storage  and  retrieval  systems. 

MANUAL  STORAGE  AND  RETRIEVAL  SYSTEMS  USING  POST-COORDINATION 

As  previously  mentioned,  a  truely  post-coordinated  indexing 
system  utilizes  one  concept  per  term.  To  search  for  information  on  a 
specific  topic,  the  component  terms  can  be  searched  for  separately,  or 
some  or  all  of  them  can  be  used.  Once  again,  it  is  important  to  emphasize 
that  the  index  term  "audible  door  alarms"  would  never  appear  in  a  system 
using  post-coordinate  index  terms.  One  would  have  to  cross  index  using 
the  component  terms  in  order  to  identify  documents  dealing  with  all  three. 

Three  types  of  manual  card  systems  employ  post-coordination, 

-  > 

each  requiring  a  card  for  storage  and  retrieval.  The  three  card  systems- 
edge-notched  cards  (item  entry),  scan  match  cards  (term  entry),  and 
peek-a-boo  cards  (term  entry)-  are  each  known  by  a  variety  of  names.  Whil 
all  of  the  names  will  be  identified,  those  shown  above  will  be  used 
throughout  the  remainder  of  this  report.  The  following  discussion 
describes  how  these  card  systems  are  organized  and  how  they  work. 

Edge-Notched  Cards 

Edge-notched  cards  are  an  item  entry  system  since  document 
information  is  contained  on  the  card  itself.  Figure  1  shows  a  card  with 
document  information  for  a  Techdata  Sheet  on  "Reinforcement  System  for 
Chain-link  Gates."  When  using  this  card  method  for  storing  and  retrieving 
doetiments,  title,  author,  publisher,  date  abstract,  and  so  on  are  recorded 
directly  on  the  card. 


All  index  terms  (descriptors)  which  relate  to  the  item  on  the 
card  are  directly  coded  into  the  outer  holes.  (A  typical  edge-notched 
card  contains  100  holes.)  When  using  this  direct  coding  method,  only  as 
many  terms  may  be  used  as  there  are  holes  on  the  card.  Each  index  term  is 
then  assigned  a  number  corresponding  to  one  of  the  numbered  holes  on  the 
card,  making  each  hole  represent  one  tern.  Holes  that  relate  to  the 
item  on  the  card  are  then  broken,  or  notched,'  so  that  the  hole  is  no 
longer  closed.  For  example,  if  gates  are  discussed  in  the  document,  and 
gates  has  been  assigned  descriptor  hole  #1,  the  hole  is  notched.  Hole  #46, 
which  is  assigned  to  the  tern  lighting,  is  not  punched  since  lighting  is 
not  discussed  in  the  document. 

Once  the  card  has  been  properly  notched,  one  can  begin  to 
retrieve  items.  Using  the  same  example,  if  the  goal  is  to  isolate  types 
of  gates,  a  rod  is  inserted  through  the  hole  assigned  to  gates.  All 
documents  dealing  with  gates  will  fall  off  the  needle  since  their  "gate” 
descriptor  hole  has  been  broken.  To  get  more  specific  and  find  a  document 
that  deals  with  gates  that  are  resistant  to  forcible  entry,  one  simply 
uses  the  fallen  pile  of  gate  documents  and  inserts  the  rod  through  the 
forcible  entry  hole.  Once  again,  all  the  items  that  use  the  index  term 
searched  for  will  fall  out  of  the  card  pack'. 


It  is  important  to  note  (see  Figure  1)  that  although  most  edge- 
notched  cards  contain  less  than  200  holes,  one  can  increase  the  amount  of 
terms  by  using  the  second  row  of  numbers  (7,4,2, 1)  in  combination  as  - 
listed  below: 


0  No  punch 
1  1 

2  2 

3  2  and  1 

4  4 


5  4  and  1 

6  4  and  2 

7  7 

8  7  and  1 

9  7  and  2 


6 


A  unique  identity  must  be  established  for  each  grouping.  Nine  descriptors 
can  be  then  utilized  for  every  four  holes  on  the  card.  The  numbers  1,  2, 

4,  and  7  require  one  pass  of  the  needle  since  only  one  hole  is  notched  to 
represent  the  number.  However,  the  numbers  3,  S,  6,  8  and  9  require  two 
passes  of  the  rod  since  each  number  is  represented  by  using  different 
combinations  of  two  holes.  This  coding  system  significantly  increases  the 
amount  of  descriptors  that  can  be  used  on  a  card.  On  an  8"  x  10lj"  card 
containing  174  holes,  the  maximum  number  of  descriptors  that  can  be  used 
is  increased  to  360. 

A  guiding  rule  is  to  choose  a  coding  scheme  that  will  minimize 
the  number  of  "false  drops."  A  false  drop  is  defined  as  a  document  produced 
by  a  search  that  does  not  use  the  index  term  being  sought.  Unfortunately, 
the  7-4-2-1  systems  carries  with  it  a  high  probability  of  producing  false 
drops.  For  example,  five  is  represented  by  notching  four  and  one,  and  nine 
is  represented  by  notching  seven  and  two.  When  both  five  and  nine  are 
used  in  the  same  grouping  on  a  card,  all  four  holes  will  be  notched.  Any 
time  any  number  in  the  grouping  is  searched  for,  the  card  will  drop.  The 
7-4-2-1  system  is  best  used  when  each  document  will  have  only  one  descrip¬ 
tor  notched  in  each  four  hole  grouping. 

The  number  of  descriptors  can  also  be  increased  by  use  of  an 
indirect  coding  scheme.  Unlike  direct  coding,  which  uses  one  hole  per 
term,  indirect  coding  uses  two  holes  per  term.  Two  number  are  assigned 
at  random  to  each  term,  (for  example,  the  index  term  "exits"  might  be 
assigned  holes  11  and  12,  or  11-12).  A  card  containing  100  holes  would  have 
00-00  to  99-99  codes — or  10,000  in  all.  However,  11-12  is  the  same  as  12- 
11  since  the  same  two  holes  are  notched.  Therefore,  the  total  nunber  of 
combinations  is  by  definition  reduced  by  half.  In  addition,  all  combina¬ 
tions  using  the  same  two  numbers  must  also  be  excluded.  Below  is  the 
equation  for  computating  the  total  number  of  operational  holes  for  a  card 
with  N  holes. 
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N  ■  total  number  of  holes 


Nu  =  number  of  unique  combinations 

Again,  consideration  must  be  made  as  to  the  probability  of  false 
drops  should  the  decision  to  use  indirect  coding  be  made.  This  probability 
could  be  greatly  reduced  by  using  a  computer  developed  random  numbers  list 
that  automatically  excluded  all  duplications  (i.e.,  11-12  and  12-11)  and 
all  diagonals  (i.e.,  11-11).  The  list  also  aids  in  scattering  the  numbers 
used  rather  than  numbering  them  sequentially. 

Scan  Hatch  Cards  (Also  known  as  Scan  Column  Cards  and  Uniterm  Cards) 

The  Scan  Match  Card  System  is  a  term  entry  system  since  cards 
identify  only  the  accession  numbers  of  documents  relating  to  the  index 
term  on 'the  top  of  the  card.  In  Figure  2,  all  the  document  numbers  listed 
relate  to  computers.  In  the  case  of  a  descriptor  requiring  further  clari¬ 
fication,  an  operational  definition  is  included  on  the  card.  This  is  done 
to  define  the  index  term,  rather  than  narrow  the  subject  heading  as  is 
done  in  pre-coordination. 

The  card  is  divided  into  10  columns.  Document  accession  numbers 
are  placed  in  the  numbered  columns  according  to  their  last  number.  This 
is  done  to  allow  the  card  to  fill  up  evenly,  as  well  as  to  make  scanning 
easier.  While  the  card  catalog  requires  one  card  for  every  document  using 
the  same  subject  heading,  the  scan  match  card  uses  one  card  for  each  index 
term.  Each  card  records  as  many  document  accession  numbers  as  the  card 
will  hold.  It  should  be  noted,  however,  that  the  search,  yields  only  a 
document  accession  number.  One  must  locate  the  document  or  refer  to  some 
secondary  cataloging  system  for  all  other  document  information. 
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Scan-Match  Cards 


Figure  2.  Scan  Match  Cards 


When  the  index  term  itself  is  not  specific  enough  to  suit  the 
searchers  needs,  this  card  method  allows  the  searcher  to  choose  a  second 
index  term  to  find  documents  using  both.  One  simply  "scans"  the  two  cards 
and  "matches"  accession  numbers  appearing  on  both.  More  descriptors  can 
be  added  depending  on  the  needs  of  the  searcher,  and  the  time  allotted 
the  searcher  to  cross  match. 

Peek-A-Boo  Cards  (Also  known  as  Optical  Coincidence  Cards) 

As  in  the  case  of  scan  match  cards,  the  peek-a-boo  system  utilizes 
a  term  entry  card  format.  The  only  information  available  to  the  searcher 
is  the  document  accession  numbers  which  fall  under  the  term.  The  searcher 
must  use  the  accession  number  to  locate  the  document  to  determine  all 
additional  information.  The  peek-a-boo  system  does  lend  itself,  however, 
to  cross-indexing  far  more  readily  than  the  scan  match  method. 

The  layout  of  a  peek-a-boo  card  is  illustrated  in  Figure  3.  It 
should  be  noted  that  while  most  peek-a-boo  cards  are  on  10"  x  12"  sheets, 
they  are  set-up  identically  to  the  card  appearing  in  the  example.  The 
only  difference  is  a  greater  number  of  boxes  which  can  accomodate  up  to 
10,000  accession  numbers.  Card  size  is  usually  adjusted  according  to 
the  number  of  documents  to  be  stored. 

Each  document  is  assigned  a  four  digit  number  which  corresponds 
to  a  position  on  the  card.  The  number  is  read  by  using  the  large  numbers 
as  the  first  two  digits  of  the  accession  number.  The  small  numbered 
boxes  within  the  large  box  contain  the  last  two  digits  (see  Figure  3) . 

Index  terms  and  any  required  definitions  appear  on  the  top  of 
the  card.  The  accession  numbers  of  the  documents  that  relate  to  the 
index  term  are  then  punched  out  leaving  a  hole.  To  determine  which  documents 
fall  under  a  given  subject,  the  card  is  simply  held  to  the  light  and  the 
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Optical  Coincidence  tFeek-^-Boo). 


Figure  3.  Peek-A-Boo  Card 


numbers  of  all  boxes  punched  are  recorded.  Cross  indexing  is  simply  a 
matter  of  placing  two  or  more  cards  together  and  holding  them  over  a  light 
box.  (A  light  box  consists  of  a  frame  with  a  sheet  of  translucent  material 
on  the  top  and  a  light  source  mounted  inside.  The  light  box  is  not  a 
necessity,  but  it  does  make  identification  of  common  holes  much  easier 
when  more  than  one  descriptor  is  used.) 

ADVANTAGES  AND  DISADVANTAGES 

Many  specific  questions  must  be  answered  before  a  decision 
can  be  made  with  respect  to  which  of  the  three  manual  information  storage 
and  retrieval  systems  will  best  suit  the  needs  of  CEL.  At  this  point, 
a  critique  of  the  alternatives,  examining  their  strengths  and  weaknesses 
is  required.  The  paragraphs  below  discuss  the  respective  advantages  and 
disadvantages  of  each  of  the  three  systems  described  above. 

Edged-Notched  Card  Method 

Advantages .  The  edge-notched  card  method  offers  storage  for  an 
unlimited  number  of  documents.  If  a  system  begins  to  have  an  unmanage¬ 
able  amount  of  cards,  they  can  easily  be  arranged  according  to  a  hierarchy 
of  terms.  Another  advantage  is  that  each  card  in  the  file  contains 
all  document  information.  In  addition,  very  little  equipment  is  required 
for  card  preparation  and  searching.  Finally,  cards  do  not  need  to  be 
kept  in  any  order  unless,  as  already  mentioned,  they  are  separated  by 
overall  subject  heading.  It  should  also  be  noted  that  the  materials 
for  this  system  are  inexpensive. 

Disadvantages.  The  most  obvious  disadvantage  of  the  edge-notched 
method  is  that  it  limits  the  number  of  descriptors,  or  index  terms,  that 
can  be  used.  There  are  ways  to  increase  the  number,  however,  which  if 
used  properly  do  not  alter  the  simplicity  of  the  system.  Another 


consideration  is  that  a  careful  coding  process  and  a  flawless  thesaurus  are 
essential.  The  thesaurus,  or  some  form  of  indexing  manual,  is  required 
to  indicate  codes  assigned  to  descriptors.  Finally,  searching  a  large 
file  presents  another  drawback  in  that  it  can  be  tedious  unless  the 
searcher  knows  what  he  needs  and  is  familiar  with  the  index  terms. 

Scan  Match  Card  Method 

Advantages.  The  scan  match  method  offers  the  capability  of  storing 
unlimited  amounts  of  documents  and  descriptors.  The  system  is  also  quite 
inexpensive.  In  fact,  many  organizations  design  and  print  their  own  cards. 

An  additional  advantage  is  that  although  the  system  is  quite  old  (late  1940's) 
step-by-step  discussions  on  how  to  choose  index  terms  for  scan  match 
systems  are  available. 

Disadvantages .  The  most  obvious  disadvantage  of  scan  match  is 
that  the  result  of  a  search  is  only  an  accession  number.  The  searcher  has 
no  knowledge  of  the  search  product  until  the  document,  or  some  secondary 
catalog,  is  consulted.  The  searcher  becomes  caught  in  somewhat  of  a  '’Catch- 
22"  situation.  If  only  two  descriptors  are  used,  the  search  result  is 
usually  large  numbers  of  documents.  Considerable  time  is  then  spent  in 
locating,  reviewing  and  screening  documents.  However,  when  he  chooses  to 
cross  four,  five  or  more  descriptors,  he  is  presented  with  the  tedious  job 
of  comparing  a  large  volume  of  accession  numbers.  Although  this  system  is 
quite  inexpensive  and  can  be  implemented  easily,  it  is  far  the  most 
difficult  system  for  daily  use. 

Peek-A-Boo  Card  Method 

Advantages .  The  peek-a-boo  card  method  has  enjoyed  popularity 
in  recent  years.  Depending  upon  the  size  of  the  card,  up  to  10,000  docu¬ 
ments  can  be  stored.  Cards  do,  however,  come  in  various  sizes  corresponding 
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to  the  number  of  documents  in  the  file.  A  forecast  to  determine  the 
projected  amount  of  documents  is  required.  The  system  also  allows  the 
use  of  as  many  index  terms  as  are  needed  and  manageable.  In  addition, 
indexing  of  new  documents  is  simply  a  process  of  punching  the  accession 
number  holes  of  the  cards  with  the  desired  descriptor.  Finally,  the 
searching  procedure  itself  is  straight-forward  regardless  of  file  size. 

Disadvantages.  Like  scan  match,  separate  accession  files  must 
be  maintained  since  searches  result  in  accession  numbers  only.  Although 
there  is  a  limit  to  the  amount  of  document  accession  numbers  that  can  be 
stored  on  each  card,  it  is  unlikely  that  CEL's  records  will  reach  10,000 
before  they  become  automated.  Accurate  punching  is  obviously  required, 
although  even  a  slightly  uncentered  punch  will  still  allow  enough  light 
through  the  card  stack  for  search  purposes.  Finally,  in  comparison  with 
the  manual  systems  already  discussed,  the  peek-a-boo  system  is  more 
expensive.  The  cost  of  commercial  peek-a-boo  cards  exceeds  that  of  cards 
used  in  other  manual  systems.  A  commercial  punch,  which  can  penetrate  a 
small  thickness  of  cards,  costs  about  $80.  A  simple  hand  punch  or  leather 
punch,  however,  has  been  found  to  be  effective.  A  light  box  is  probably 
the  most  expensive  of  all  the  equipment  to  be  purchased  (approximately  $150). 

Table  1  summarizes  the  differences  among  the  three  manual  systems 
by  describing  them  in  terms  of  system  constraints,  operational  characteris¬ 
tics  and  automation  considerations. 

The  number  of  documents  and  descriptors  that  the  manual  systems 
can  employ  (see  Table  1)  are  described  in  terms  of  "absolute"  and  "practical. 
This  distinction  has  been  made  to  differentiate  between  the  saturation  point 
of  a  system  and  its  realistic  working  limitations.  Eventually,  rapidly 
growing  information  systems  may  operate  more  efficiently  by  using  automation 
technology.  Manual  systems  are  practical,  however,  as  long  as  one  is 
aware  of  where  system  inefficiency  occurs  in  terms  of  maximum  number  of 

14 


descriptors  and  documents.  Manual  systems  that  suit  the  needs  of  a  newly 
developed  library  may  require  replacement  as  files  become  larger  and  more 
complex.  Therefore,  when  selecting  a  manual  system  it  is  important  to 
recognize  its  strengths  and  weaknesses,  in  addition  to  file  characteristics 
and  future  growth  potential. 

ANALYSIS  OF  MANUAL  SYSTEMS 

In  determining  which  of  the  three  systems  discussed  would  best 
suit  CEL's  need  for  an  information  storage  and  retrieval  system,  three 
criteria  were  given  close  examination.  Search  procedure,  search  output 
and  compatability  with  automated  systems  were  found  to  be  the  most  important 
aspects  in  choosing  a  system.  After  identifying  and  examining  these 
criteria,  the  edge  notched  card  system  has  been  determined  to  be  the 
roost  suitable  manual  information  storage  and  retrieval  system  for  use  by 
CEL. 


The  scan  match  card  system  is  extremely  tedious  and  time  consuming 
system  when  searching  on  a  daily  basis.  The  product  of  a  scan  match  search 
is  only  an  accession  number.  In  order  to  obtain  specific  information, the 
document,  or  a  secondary  cataloging  system,"  must  be  consulted.  The  scan 
match  system  also  limits  the  ease  of  conversion  from  manual  to  automated 
systems.  Document  information  cannot  be  entered  directly  from  the  search 
card  without  consulting  a  secondary  source.  Mission  Research  Corporation 
does  not  recommend  using  the  scan  match  system  for  these  reasons. 

The  peek-a-boo  card  system  has  essentially  the  same  operational 
constraints  as  the  scan  match  card  system,  however,  the  actual  search 
procedure  is  straightforward.  Like  scan  match,  the  product  of  a  peek-a- 
boo  search  is  an  accession  number.  Again,  one  must  go  elsewhere  to  locate 
specific  information  concerning  the  documents  identified  in  the  search. 

The  peek-a-boo  system  also  limits  the  ease  with  which  documents  can  be 


16 


entered  into  an  automated  system.  Reading  accession  numbers  off  peek-a-boo  card 
during  the  transition  from  a  manual  to  an  automated  system  cannot  be  done 
efficiently  or  reliably  by  the  user.  Although  automatic  scanners  that 
"read"  the  cards  do  exist,  they  are  costly  as  well  as  unreliable.  Due 
to  these  system  limitations,  the  peek-a-boo  card  system  is  not  recommended 
for  use  by  CEL. 

MRC  feels  the  edge-notched  card  system  is  the  most  desirable 
manual  system  for  CEL  due  to  the  simplicity  of  the  search  procedure,  the 
extent  of  the  search  output,  and  its  compatibility  with  automated  systems. 

Coding  schemes  are  available  that  sufficiently  increase  the  number  of 
descriptors  that  can  be  utilized  withou  losing  the  desired  sinplicity  of 
the  search  procedure.  Furthermore,  since  edge-notched  cards  employ  an 
item  entry  format,  all  document  information  is  produced  directly  from  the 
search  itself  without  consulting  secondary  catalogs.  Edge-notched  cards 
also  allow  efficient  transition  from  a  manual  system  to  an  automated  one 
since  each  card  contains  document  information  in  a  manner  that  is  compatible 
with  computer  format.  Although  edge-notched  cards  have  been  found  to  be 
the  superior  manual  system,  it  should  be  noted  that  a  concurrent  analysis 
of  computerized  information  systems  is  being  done  to  determine  if  an 
automated  system  will  better  suit  the  needs  of  CEL. 

IMPLEMENTATION  OF  EDGE-NOTCHED  CARD  SYSTEM 

The  thesaurus  provided  by  CEL  has  been  reviewed  by  the  MRC 
project  team  and  found  to  be  compatible  with  CEL  requirements.  Should 
a  manual  system  be  desired,  MRC  has  detailed  an  implementation  plan  for 
edge-notched  cards  using  the  indexing  structure  identified  in  the  thesaurus. 

The  indexing  thesaurus  divides  search  terminology  into  eight 
general  catagories,  referred  to  as  Hierarchy  Terms  (HT) .  These  terms  are: 
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Alarm  Technology  (AT) 

Lock  Technology  (LT) 

Control  (CON) 

Methods  of  Entry  (MOE) 

Types  of  Entry  (TYE) 

Builders  Hardware  (BH) 

Security  Administration  and  Management  (SAM) 

Facilities,  Locations  (FAC) 

Each  HT  is  then  divided  into  major  subject  headings.  Subject  headings 
are  further  divided  into  their  component  parts  which  constitute  the  third 
level  of  indexing  terminology.  Table  2  illustrates  the  total  number  of 
index  terms  for  each  HT  found  in  the  CEL  Indexing  Thesaurus.  This  table 
was  developed  to  determine  the  feasibility  of  an  edge-notched  card  system 
in  light  of  the  number  of  index  terms  used  in  the  thesaurus. 

As  previously  stated,  the  number  of  index  terms  that  can  be 
used  with  an  edge-notched  card  system  depends  upon  the  size  of  the  card 
and  how  many  holes  it  contains.  This  number  can  be  increased  by  using 
various  combinations  of  two  holes,  as  done  in  indirect  coding  schemes. 

MRC  feels  that  indirect  coding  is  sufficiently  manageable  to  be  employed 
in  the  data  management  system  outlined  for "use  by  CEL.  Separate  card 
files  would,  however,  be  established  for  each  hierarchy  term. 

Commercial  8"  x  10V  cards  have  174  holes  that  can  be 
coded  directly  for  a  maximum  of  174  terms,  that  is,  one  hole 
per  term.  By  using  the  same  size  card  and  employing  indirect  coding,  only 
the  first  100  holes  are  used  to  increase  the  total  number  to  4,950. 

To  keep  the  system  manageable  and  prevent  false  drops,  however,  the 
index  terms  used  should  be  limited  to  a  practical  number.  As  shown  in 
Table  2  the  highest  number  of  descriptors  for  any  single  Hierarchy  Term 
(HT)  is  329.  By  using  direct  coding  for  some  hierarchy  terms  and  indirect 
coding  for  others,  edge-notched  cards  can  be  sucessfully  used  to  contain 
the  number  and  complexity  of  index  terms  identified  in  the  CEL  thesaurus. 
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Subtotals 


HIERARCHY  TERM 

2nd  LEVEL  TERMS 

3rd  LEVEL  TERMS 

4th.  LEVEL  TERMS 

TOTAL 

AT* 

36 

181 

0 

217 

IT* 

33 

296 

0 

329 

CON 

14 

57 

31 

102 

MOE 

13 

76 

26 

115 

TYE 

18 

0 

0 

18 

BH* 

51 

98 

14 

163 

SAM 

6 

21 

2 

29 

FAC 

23 

8 

0 

31 

TOTALS 

194 

737 

73 

1004 

Note:  Those  hierarchy  terms  followed  by  an  asterisk  (*)  represent  the 
files  that  would  require  use  of  an  indirect  coding  scheme  due  to 
the  number  of  index  terms.  All  others  are  small  enough  to  use 
the  direct  coding  method. 


Table  2.  Number  of  Descriptors  Used  for  Each  Hierarchy  Term 


Each  hierarchy  teen,  representing  one  unique  set  of  cards  (a 
file),  uses  a  specific  set  of  index  terms.  For  those  HTs  compatible  with 
the  direct  coding  method,  assigned  hole  sequence  follows  the  alphabetical 
listing  used  in  the  thesaurus.  That  is,  holes  are  assigned  to  terms  by 
starting  at  a  specified  point  on  the  card  and  continuing  around  it, 
following  the  order  of  the  terms  as  they  appear  in  the  thesaurus.  The 
hole  location  of  each  assigned  term  must  be  noted  on  the  thesaurus. 

For  those  HTs  that  necessitate  the  use  of  an  indirect  coding 
scheme,  holes  should  be  assigned  randomly.  Numbers  are  assigned  randomly 
in  order  to  reduce  the  possibility  that  a  combination  has  not  been  used 
more  than  once.  As  previously  stated,  the  coding  choices  exclude  duplications 
and  diagonals.  The  random  list  also  aids  in  scattering  those  holes  which 
axe  used  throughout  the  entire  card  rather  than  concentrating  them  in  one 
section  of  the  card. 

Once  index  term  assignments  are  made  and  recorded,  and  documents 
are  classified  according  to  the  terms  identified  in  the  thesaurus,  document 
information  is  transcribed  onto  the  edge  notched  card  itself.  Holes  art 
punched  according  to  the  terms  used  to  identify  the  document.  Information 
about  the  document,  such  as  title,  author,  accession  number,  abstract, 
and  descriptor  list,  is  placed  on  the  body  of  the  card  according  to  the 
level  of  detail  desired.  A  document  abstract,  if  desired,  can  be  placed 
on  the  reverse  side  of  the  card.  It  may  be  desirable  to  have  three 
separate  formats  each  representing  a  specific  type  of  document:  biblio¬ 
graphic/annotation  form,  vendor  publication  form,  and  CEL  inhouse  report 
form.  Each  format  would  include  a  form  title  and  a  corresponding  colored 
line  for  easy  visual  identification. 


CONCLUSION 


MRC  finds  the  edge  notched  card  system  to  be  the  most  suitable 
manual  information  storage  and  retrieval  system  for  use  by  CEL.  Document 
information  is  recorded  and  stored  in  a  manner  that  is  compatible  with  the 
way  in  which  it  will  later  be  retrieved  and  used.  Computerized  infor¬ 
mation  systems  are  being  analyzed  to  determine  if  they  can  provide  CEL 
with  abilities  that  go  beyond  the  scope  of  manual  systems.  Should  a  manual 
system  be  chosen,  the  edge  notched  card  system  is  further  recommended 
due  to  its  operational  characteristics  and  the  ease  with  which  it  can  later 
be  automated. 
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20.  ABSTRACT  (Continued) 

security  Research,  Development,  Test  and  Evaluation  (RDT&E)  functions. 

The  Data  Management  System  is  a  direct  response  to  the  CEL  staff's  in- 
house  need  for  effective  and  efficient  storage  and  retrieval  of  data 
and  documentation  to  support  RDT&E  tasks  and  physical  security  problem¬ 
solving  for  the  Naval  Shore  Establishment.  The  scope  of  CEL's  current 
in-house  RDT&E  documentation  relates  to  a  broad  range  of  physical 
security  information  domains  including  alarm  technology,  lock  technology, 
control  equipment,  methods  of  entry,  types  of  entry  (threats),  builders 
hardware,  security  administration  and  management,  facilities  (locations), 
barrier  technology,  attack  resistant  materials,  and  other  specific  RDT&E 
physical  security  categories  in  response  to  new  forms  of  attacks  against 
Naval  Shore  installations  and  facilities.  The  manual  presents  (1)  an 
overview  of  the  Data  Management  System's  hardware  and  software  capabili¬ 
ties  including  a  description  of  the  system  configuration,  (2)  user  in¬ 
structions  for  completion  of  the  Physical  Security  Data  Management  Sys¬ 
tem  Input  Sheet,  (3)  user  instructions  for  entry  of  data  into  the  on-line 
Data  Management  System  once  an  Input  Sheet  has  been  completed,  (4)  a 
description  of  batch  outputs  of  the  Data  Management  System  including  the 
Master  List,  Keyword  Index  and  Keyword  Count,  and  (5)  user  instructions 
for  execution  of  data  file  searches  in  an  interactive  batch  mode. 
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SECTION  1 
INTRODUCTION 


1.1  BACKGROUND 

The  Civil  Engineering  Laboratory  (CEL)  of  the  Naval  Construction 
Battalion  Center,  Port  Hueneme,  California,  initiated  a  project  during 
FY  1979  for  the  development  of  an  in-house  Physical  Security  Data  Manage¬ 
ment  System.  This  project  is  a  direct  response  to  the  CEL  staff's  need  for 
effective  and  efficient  storage  and  retrieval  of  in-house  data  and  docu¬ 
mentation  to  support  physical  security  problem-solving  by  CEL  for  the  Naval 
Shore  Establishment. 

The  scope  of  CEL's  current  in-house  Research,  Development,  Test 
and  Evaluation  (RDT§E)  data  and  documentation  relate  to  a  broad  range  of 
physical  security  information  domains.  These  domains  include  Alarm  Tech¬ 
nology;  Lock  Technology;  Control  Equipment;  Methods  of  Entry;  Types  of 
Entry,  Threats;  Builders  Hardware;  Security  Administration  and  Management; 
Facilities,  Locations;  Law  Enforcement  Technology  and  Criminal  Justice; 
Shore-Based  Security  Technology  supporting  shipboard  security  requirements 
(at  shore-based  facilities);  Barrier  Technology;  Attack  Resistant  Mate¬ 
rials;  and  a  number  of  standardized  categories  relating  to  architecture  and 
engineering  such  as  those  set  forth  in  Sweet's  Catalog  File  and  the  Uniform 
Construction  Index.* 

*  Sweet's  Catalog  File  is  an  annual  publication  designed  for  use  by 

architectural  engineers.  The  Guide  contains  manufacturers'  product  in¬ 
formation  which  is  organized  according  to  16  major  subject  headings 
(e.g.,  concrete,  masonry,  metals,  woods  and  plastics,  and  doors  and 
windows).  The  Uniform  Construction  Index  (UCI)  is  a  publication  of  the 
Construction  Specifications  Institute  (CSI)  that  presents  a  coordinated 
system  of  formats  for  specifications,  data  filing,  cost  analysis  and 
project  filing.  The  UCI  is  based  on  the  16  divisions  of  Sweet's  Guide. 


Traditional  systems  for  information  storage  and  retrieval,  rang¬ 
ing  in  sophistication  from  shoe  boxes  stuffed  with  filing  cards  to  more 
elaborate  manual  systems  with  multi-tiered  categorization  schemes  and  in¬ 
dexing  thesauri,  only  can  meet  information  requirements  up  to  a  certain 
level  of  detail.  In  the  case  of  the  CEL  staff's  requirements,  the  research 
performed  indicated  that  manual  systems  rapidly  reach  the  limits  of  their 
capabilities  when  the  usable  output  information  that  is  required  is  very 
specific . * 


Additional  investigation  revealed  that  the  conversion  of  a  manual 
system  to  an  automated  one  can  yield  significantly  better  outputs  for  the 
user  at  a  relatively  low,  or  even  negligible,  additional  cost.  The  trade¬ 
off  analysis  between  the  manual  and  automated  systems  under  consideration 
turned  on  the  issue  of  specificity  of  information.  As  the  automation 
feasibility  analysis  noted,  CEL  staff  members  every  day  need  to  access  and 
use  technical  data  from  a  wide  variety  of  technical  sources  in  performance 
of  their  physical  security  RDT&E  functions.  The  technical  sources  include 
DoD  reports,  government  laboratory  reports,  commercial  product  catalogs, 
military  specifications  and  standards,  DoD  directives  and  manuals,  service 
regulations,  research  texts,  contractor  reports,  in-house  technical  notes 
and  data  sheets,  and  reference  texts.  At  present,  there  are  an  estimated 
600  separate  items  in  the  CEL  in-house  physical  security  document  collec¬ 
tion  and  it  is  growing  rapidly. 


*  Benner,  P.,  Caldwell,  J.  and  Solomonson,  D.,  Development  of  a  Physical 
Security  Data  Management  System,  Volume  I .  Manual  Information  Storage 
and  Retrieval  Systems,  MRC/WDC-R-003 ,  Mission  Research  Corporation, 
September  1979. 

The  results  of  this  investigation  will  be  documented  in  a  separate 
technical  report  to  be  entitled,  "Automation  Feasibility  Analysis." 
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CEL  staff  utilization  of  the  above  source  materials  is  often 
very  specific.  For  example,  the  need  to  quickly  access  relevant  information 
about  multiple-bolt  door  locking  systems,  which  must  meet  a  minimum  delay 
timeline  as  set  forth  in  a  military  specification,  is  one  indication  of  the 
level  of  specificity  required  when  information  searches  are  undertaken. 
Another  example  is  accession  of  the  types  of  materials  available  for  con¬ 
struction  of  a  security  guard  shack  which  are  resistant  to  .30  caliber 
automatic  weapons  fire.  While  these  illustrations  do  not  indicate  the  full 
range  of  queries  to  which  the  CEL  staff  responds  every  day,  they  indicate 
the  level  of  technical  detail  which  is  often  required.  Most  naval  users 
want  explicit  answers  to  explicit  questions,  and  they  generally  want  detailed 
and  reliable  information  in  a  hurry,  sometimes  to  solve  an  immediate  opera¬ 
tional  problem. 

1.2  SYSTEM  PURPOSE  AND  REPORT  ORGANIZATION 

This  Users'  Manual  describes  the  CEL  Physical  Security  Data 
Management  System  from  the  point  of  view  of  in-house  CEL  staff  members  who 
will  use  the  system.  Section  2  is  an  overview  of  the  system's  hardware 
and  software  capabilities  and  includes  a  description  of  the  system  config¬ 
uration.  Section  3  presents  user  instructions  for  completion  of  the  Physi¬ 
cal  Security  Data  Management  System  Input  Sheet  (hereinafter  Data  Input 
Sheet)  that  has  been  designed  and  tested  for  preparation  of  records  to  be 
entered  into  the  on-line  system.  Section  4  presents  user  instructions  for 
entry  of  data  into  the  on-line  Data  Management  System  once  a  Data  Input 
Sheet  has  been  completed.  Section  5  describes  the  batch  outputs  of  the  Data 
Management  System  including  the  Master  List,  Keyword  Index  and  Keyword  Count. 
Section  6  outlines  the  scope  of  prospective  user  instructions  for  execution 
of  data  searches  from  a  remote  terminal  in  an  interactive  batch  mode. 
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SECTION  2 

OVERVIEW  OF  DATA  MANAGEMENT  SYSTEM 


2.1  GENERAL  DESCRIPTION 

The  Physical  Security  Data  Management  System  is  an  information 
storage  and  retrieval  system  specifically  designed  for  the  CEL  Physical 
Security  Laboratory  research  staff.  Four  user  criteria  were  applied  to 
the  development  effort.  First,  the  system  has  been  developed  to  support 
the  CEL  staff  as  in-house  users.  Second,  it  has  been  designed  to  provide 
outputs  at  a  level  of  detail  that  is  specific  to  user  needs.  Third,  it 
has  been  designed  for  simplicity  of  user  operation.  Fourth,  it  has  been 
designed  for  economy  of  operation. 

The  current  capabilities  of  the  Physical  Security  Data  Management 
System  are  based  on  a  software  package,  known  as  FAMULUS,  which  is  operat¬ 
ing  on  an  I  tel  Advanced  System  6  (AS/6)  at  the  Computer  Center  of  the  Uni¬ 
versity  of  California,  Santa  Barbara.  FAMULUS  is  an  integrated  set  of 
FORTRAN  IV  programs  for  information  storage  and  retrieval.  It  consists  of 
11  programs  that  enable  the  user  to  create,  correct,  update,  sort  and 
merge,  index,  search  and  print  large  files  of  bibliographical  information. 
The  programs  are  simple  to  use  and  the  costs  are  moderate  on  the  UCSB 
hardware.  A  more  detailed  exposition  of  FAMULUS  is  set  forth  in  the 
FAMULUS  Users'  Manual  in  the  Appendix. 


In  summary,  the  selection  was  based  on  five  straightforward  con¬ 
siderations.  First,  it  is  a  fully  debugged  system  which  is  "up  and  running. 


Second,  there  is  no  software  purchase  cost.  FAMULUS  is  free  to  any  user. 
Third,  it  is  operating  at  the  UCSB  Computer  Center  where  CEL,  as  a  govern¬ 
ment  laboratory,  is  a  welcome  user.*  Fourth,  FAMULUS  is  operating  within 
a  user  community  that  uses  the  software  continuously.  The  support  services 
for  FAMULUS,  including  enhancements,  are  excellent  at  the  UCSB  Computer 
Center.  Fifth,  there  is  persuasive  evidence  that  the  FAMULUS  programs  are 
easily  transferable  from  one  IBM  mainframe  to  another  or  to  an  IBM  plug- 
compatibie  mainframe. '  In  short,  the  Itel  AS/6-FAMULUS  arrangement  is 
cost-effective. 


2.2  SYSTEM  CONFIGURATION 


Figure  1  is  a  flow  chart  showing  the  principal  procedures  that 
have  been  built  into  the  Physical  Security  Data  Management  System.  The 
system  consists  of  a  series  of  execute  files  which  facilitate  the  entry  of 
bibliographical  records  into  an  on-line  file,  and  a  series  of  FAMULUS  pro¬ 
grams  which  generate  printed  output  reports  and  which  permit  on-line  entry 
of  instructions  for  file  searches. 

*  During  FY  1980,  the  CEL  staff  is  planning  to  procure  a  remote  printing 
terminal  linked  to  the  UCSB  Computer  Center  by  dedicated  modems.  This 
system  will  enable  direct  Data  Management  System  file  access  for  searches 
in  an  interactive  batch  mode.  The  terminal  that  will  be  procured  in 
FY  1980  is  a  Data  General  DASHER  TP2,  Model  KSR  6077-J.  Procurement  of 
the  Data  General  hardware  was  based  on  a  technical  analysis  of  a  number 
of  commercially  available  printing  terminals. 

FAMULUS  originally  was  developed  at  the  University  of  California, 
Berkeley,  on  a  CDC  6400.  Subsequently,  it  underwent  an  IBM  360  conver¬ 
sion  at  the  University  of  California,  Los  Angeles  (UCLA).  At  UCLA,  a 
version  of  FAMULUS  was  made  available  to  University  College,  London, 
whence  it  was  acquired  by  the  UCSB  Computer  Center.  At  UCSB,  FAMULUS 
was  initially  implemented  on  an  IBM  360/75  and  a  number  of  significant 
software  enhancements  were  added.  When  the  IBM  360/75  was  replaced 
with  the  Itel  .AS/6,  the  transfer  of  FAMULUS  to  the  .AS/6  required  no  con¬ 
version,  The  Itel  AS/6  is  a  plug-compatible  processor,  equivalent  to 
IBM  570  Systems  and  an  effective  replacement  for  older  IBM  System/360 
models.  The  CEL  Computer  Center  currently  has  the  capability  of  two 
high-speed  remote  batch  terminals  connected  by  dedicated  telephone  lines 
to  three  data  centers  including  an  IBM  370/165  operated  by  the  Naval  Con¬ 
struction  Battalion  Center  at  Port  Hueneme,  California.  The  Physical 
Security  Data  Management  System  could  be  transferred  to  this  370/165. 
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The  lefthand  column  sequence  shown  on  Figure  1  indicates  the  data 
preparation  procedure  for  reading  a  CEL  in-house  document  and  preparing  a 
Physical  Security  Data  Management  System  Input  Sheet.  Specific  instruc¬ 
tions  for  this  procedure  are  described  in  Section  3. 

The  next  column  sequence  indicates  the  data  input  procedure  for 
entering  a  completed  Input  Sheet  into  the  computer.  The  procedure  consists 
of  keying  in  specific  information  for  each  field  through  use  of  an  on-line 
text  editing  system  operating  on  the  Itel  AS/6  at  the  UCSB  Computer  Center. 
This  system  is  known  as  WYLBUR.  WYLBUR  facilitates  entry  of  bibliographi¬ 
cal  data  into  a  Temporary  Raw  Data  File,  pre-processing  of  the  raw  data 
into  an  expanded,  clean  Input  Data  File,  and  creation  of  a  Master  CEL 
FAMULUS  File  as  well  as  an  off-line  magnetic  tape  Backup  File.  Specific 
instructions  for  this  procedure  are  described  in  Section  4. 

The  next  column  sequence  indicates  the  data  output  procedure  for 
generating  a  printed  report.  The  procedure  involves  the  application  of 
FAMULUS  report  programs  to  the  records  stored  in  the  Master  CEL  FAMULUS 
File.  Three  basic  types  of  reports  can  be  generated:  (1)  a  Master  List 
sorted  by  accession  number,  (2)  a  Keyword  Index  that  is  alphabetized,  and 
(3)  a  Keyword  Count  that  is  a  statistical  listing  indicating  the  frequency 
with  which  each  keyword  appears  in  the  data  file  sorted  both  alphabetically 
and  by  frequency  (high  to  low  in  descending  order).  Specific  instructions 
for  this  procedure  and  for  interpreting  the  report  outputs  are  described  in 
Section  5. 


The  righthand  column  sequence  indicates  the  interactive  batch 
search  procedure  for  finding  specific  records  according  to  a  variety  of 
search  keys,  especially  keywords.  Interactive  batch  refers  to  the  capa¬ 
bility  interactively  to  construct,  submit  and  manipulate  jobs,  which  are 
processed  in  a  batch  mode,  and  to  obtain  batch  outputs  remotely.  In  other 
words,  a  user  may  enter  a  search  query  from  a  remote  terminal  (e.g.,  the 
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Data  General  DASHER  TP2  terminal  after  it  is  procured  by  the  U.S.  Navy  for 
the  CEL  staff).  If  the  computer  is  not  experiencing  heavy  user  telepro¬ 
cessing  traffic,  the  turnaround  time  is  very  short.  If  the  computer  has  a 
long  queue  of  jobs,  the  system  can  be  queried  later  (e.g.,  ranging  from  a 
few  minutes  to  overnight)  and  the  resultant  output  can  be  printed  out  after 
the  job  has  been  run.  This  procedure  is  prospectively  outlined  in  Section 
6  and  will  be  fully  documented  after  procurement  of  the  Data  General 
terminal . 
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SECTION  3 

USER  INSTRUCTIONS  FOR  DATA  INPUT  SHEET 


3.1  INPUT  SHEET  INSTRUCTIONS 

The  first  step  after  selection  of  a  document  for  entry  into  the 
Physical  Security  Data  Management  System  is  completion  of  a  Data  Input  Sheet 
(see  Exhibit  1).  This  form  is  the  key  to  the  successful  operation  of  the 
information  storage  and  retrieval  system.  Once  the  data  on  the  sheet  have 
been  entered  into  an  on-line  storage  file,  the  user  can  access  by  keywords 
any  information  about  the  document  recorded  in  nine  of  the  ten  fields. 

This  information  includes  a  full  bibliographical  citation,  a  keyword  list, 
useful  annotations,  an  abstract  and  an  accession  number  with  which  to  find 
the  document  in  the  CEL  in-house  library. 

The  Data  Input  Sheet  is  divided  into  ten  fields  (0-9)  as  shown  in 
Exhibit  1.  Each  field  is  a  separate  space  on  the  sheet  for  recording  spe¬ 
cific  information  concerning  the  document  or  its  contents.  The  paragraphs 
which  follow  describe  how  to  complete  each  field. 

3.1.1  Field  0:  Accession  Number 

Each  document  is  first  assigned  an  accession  number  according  to 
type  of  document.  At  present,  there  are  nine  types  of  documents  each  de¬ 
signated  by  a  two’  letter  alpha  prefix  as  shown  below. 

BK  -  Book 


PC 


Product  Catalog 


Exhibit  1.  Data  Input  sheet. 
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PE  - 

Periodical 

RD 

Defense  Report 

RL 

Research  Laboratory  Report 

RT 

Reference  Text 

TN 

Technical  Note 

OR 

Other  Report 

0T 

Other 

One  of  the  nine  prefixes  must  be  selected  and  then  a  number 
assigned  (between  00001  and  99999).  Numbers  are  always  sequential  and 
left  zero  filled.*  Each  of  the  nine  prefixes  is  defined  below. 

Book  (BK) 


A  book  is  any  published  commercial  text  dealing  with  the  subject 
of  physical  security  in  any  of  its  aspects.  It  can  be  either  hardbound  or 
paperback. 

Product  Catalog  (PC) 

A  product  catalog  is  any  brochure,  advertisement,  or  qualitative/ 
quantitative  enumeration  of  items  that  describes  physical  security  equip¬ 
ment  and/or  services. 

Periodical  (PE) 

A  periodical  is  any  magazine,  journal,  or  serial,  published  at 
regular  intervals,  which  relates,  directly  or  indirectly,  to  physical  security. 

*  With  the  assignment  of  an  accession  number  between  1  and  99999,  the  number 
is  entered  in  the  accession  number  field,  the  least  significant  digit  in 
the  rightmost  column,  and  then  all  other  unused  columns  are  filled  with 
zeros,  e.g.,  00001,  00011,  00111,  etc.,  for  1,  11  and  111,  respectively. 
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Defense  Report  (RD) 

A  defense  report  is  any  document  published  by  agencies  of  the 
Department  of  Defense  (DoD)  or  the  Departments  of  the  Army,  Navy,  or  Air 
Force.  The  exception  is  any  report  published  by  a  DoD  or  service  laboratory. 
These  reports  are  classified  as  research  laboratory  reports.  See  the 
definition  below. 

Research  Laboratory  Report  (RL) 

A  research  laboratory  report  is  any  document  published  by  a  U.S. 
Government  or  private  laboratory,  including  U.S.  military,  foreign  and 
international  laboratories,  engaged  in  research  and  development  activities. 
When  one  or  more  other  categories  appear  appropriate  for  classification  of 
a  document,  this  category  takes  precedence. 

Reference  Text  (RT) 

A  reference  text  is  any  technical,  scientific,  legal,  regulatory, 
or  prescriptive  material  which  relates  directly  or  indirectly  to  physical 
security.  This  category  is  very  broad  but  includes  such  materials  as 
Federal  statutes,  DoD  directives,  service  regulations,  military  specifica¬ 
tions,  etc. 

Technical  Note  (TN) 

1 

A  technical  note  is  any  in-house  CF.L  document  that  does  not 
easily  fit  into  any  of  the  other  categories  (e.g.,  progress  reports,  de¬ 
sign  notes,  and  proposals).  It  does  not  include  published  Technical 
Memoranda  or  Technical  Data  Sheets.  These  documents  are  research  labora¬ 
tory  reports  and  belong  to  the  RL  category. 
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Other  Report  (OR) 

Other  reports  are  any  documents  published  by  a  non-DoD  agency  or 
other  public  or  private  organization  which  does  not  fit  into  the  research 
laboratory  category.  Research  publications  of  the  Federal  Bureau  of  Inves¬ 
tigation,  the  Law  Enforcement  Assistance  Administration  and  the  Interna¬ 
tional  Association  of  Chiefs  of  Police  are  examples. 

Other  (OT) 

This  category  is  reserved  for  published  and  unpublished  material 
that  does  not  fit  into  any  of  the  above  categories. 

3.1.2  Field  1:  Year 

In  this  field,  record  the  year  of  publication  followed  by  the 
month  of  publication  if  shown  on  the  document.  Record  the  full  year  (e.g., 
1979)  and  the  number  of  the  month  right  justified  (e.g.,  07  for  July). 

Leave  one  space  between  the  year  and  the  month.  It  is  important  to  enter 
the  dates  in  the  specified  sequence  because  the  FAMULUS  program  searches  by 
>ear  and  then  by  month. 

3.1.3  Field  2:  Report  ilumber/Contract  Number 

In  this  field,  enter  any  report  and/or  contract  numbers.  These 
numbers  must  be  separated  by  a  semicolon.  The  report  number  should  be 
entered  first. 

3.1.4  Field  3:  Author(s) 

In  this  field,  enter  the  full  names  of  all  authors.  Enter  last 
name  first,  then  first  name  and  middle  initial.  A  semicolon  must  be 
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used  to  separate  multiple  authors.  In  the  case  of  a  periodical,  list  all 
authors  of  pertinent  articles.  In  the  case  of  a  collection  of  articles  or 
chapters  where  only  an  editor  is  listed,  enter  the  editor’s  name. 

3.1.5  Field  4:  Title  and  Page  Count 

In  this  field,  enter  the  full  title,  then  enter  a  semicolon  and 
then  enter  the  total  number  of  pages  in  parentheses.  If  only  one  article 
in  a  journal  is  cited,  the  journal  title  follows  the  article  title  and  the 
page  count.  The  volume  and  number  of  the  journal  follow  the  page  count  as 
appropriate  separated  by  a  semicolon.  If  the  whole  journal  is  being  entered 
into  the  system,  the  pertinent  individual  titles  may  be  entered  in  the  abstract. 
Field  9,  and  the  name  of  the  journal  will  suffice  for  the  title. 

3.1.6  Field  5:  Publisher 

In  this  field,  enter  the  publisher's  name.  In  the  three  sub¬ 
fields  which  follow,  enter  Performing  Organization,  Controlling  Office,  and 
Monitoring  Agency  as  appropriate.  These  three  subfields  conform  to  the 
instructions  for  preparation  of  a  Report  Documentation  Page  of  a  DoD  re¬ 
search  document  (DD  Form  1473).*  Each  of  these  subfields  is  defined  below. 

Performing  Organization 

For  in-house  reports,  enter  the  name  of  the  performing  activity 
including  agency,  division,  department,  bureau,  etc.,  if  appropriate.  For 
contractor  or  grantee  reports,  enter  the  name  of  the  contractor  or  grantee 
who  prepared  the  report  and  identify  the  appropriate  corporate  division, 
school,  laboratory,  etc.,  of  the  author. 

*  Standards  for  DNA  Scientific  and  Technical  Reports,  pp.  A-l  and  A-2. 

Defense  Nuclear  Agency,  16  July  1979. 
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Controlling  Office 

Enter  the  name  of  the  controlling  office.  The  controlling  office 
equates  to  the  funding/ sponsoring  agency  if  indicated.  Otherwise,  leave  blank. 

Monitoring  Agency 

This  field  should  be  used  when  the  controlling  or  funding  office 
does  not  directly  administer  a  project,  contract,  or  grant,  but  delegates 
the  administrative  responsibility  to  another  organization  if  indicated. 
Otherwise,  leave  blank. 

3.1.7  F i el d  6 :  Keywords 

Review  the  document  thoroughly  to  identify  the  important  contents 
and  concepts  which  relate  to  physical  security.  If  an  abstract  has  already 
been  prepared,  this  is  a  valuable  source.  Identify  all  keywords  pertaining 
to  the  contents  and  concepts  identified.  Enter  all  keywords  which  are  con¬ 
tained  within  either  the  Dataflow  Thesaurus*  or  the  Keyword  Count  Report 
described  in  Section  5  below.  The  Thesaurus  and  Keyword  Count  constitute 
the  controlled  vocabulary  of  the  Data  Management  System.  This  field  is  the 
principal  source  for  file  searches  and  the  basis  of  the  indexing  system. 
Accordingly,  the  review  should  be  thorough.  Multiple  keywords  should  be 
separated  by  semicolons.  Interesting  words  and  phrases,  which  are  not 
appropriate  as  keywords,  but  which  serve  to  illuminate  the  contents  of  the 
document,  should  be  held  for  entry  in  the  next  field. 


*  Indexing  Thesaurus,  Dataflow  Systems,  Incorporated,  June  1975.  Annot: 

As  experience  in  implementation  of  the  Data  Jlanagement  System  is  gained, 
the  Thesaurus  will  be  modified  to  delete  and/or  include  new  terms  as 
appropriate. 
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3.1.8  Field  7:  Annotation 

In  this  field,  enter  any  words  or  phrases  that  enhance  a  user's 
understanding  of  the  document's  overall  contents.  Specific  data  references 
are  also  appropriate  here  including  military  specifications.  Multiple 
terms  should  be  separated  by  semicolons. 

3.1.9  Field  8:  Reserve  Field 

This  field  currently  is  not  being  used.  Leave  blank.  The  func¬ 
tion  of  this  field  is  being  reserved  for  any  future  data  requirement  that 
may  arise. 

3.1.10  Field  9:  Abstract 

The  abstract  should  be  a  brief,  factual  summary  of  the  most  sig¬ 
nificant  information  contained  in  the  document,  not  to  exceed  350  words. 

It  should  state  the  purposes  of  any  research  reported,  what  was  learned, 
and  how,  and  the  conclusions  obtained.  If  the  report  contains  a  signifi¬ 
cant  bibliography  or  literature  survey,  mention  the  results  here.  If  an 
abstract  is  already  provided  in  the  document,  incorporate  language  as 
appropriate,  especially  if  it  is  a  DD  Form  1473,  as  noted  above  under  Field  5, 

3.2  OPERATIONAL  EXAMPLE 

Exhibit  2  provides  an  example  of  a  completed  Data  Input  Sheet. 

A  recently  published  CEL  Technical  Memorandum  has  been  used  for  this 
illustration.  This  particular  report  includes  an  entry  in  every  field 
except,  of  course,  the  reserve  field,  Field  8. 
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Exhibit  2.  Example  of  completed  data  Input  sheet 


^OUrtCt  -tOix 

Provides  graphic  docuwenmlon  of  (1)  Inttelletlon  procei 
for  heavy  steel  door;,  hollow  doors  and  inward  opening  atrsonnal  doors:  17) 
an  erorggncy  forciblt  entry;  (3)  hardware  c  owe  orients  of  hasp/lock  system: 
(*)  tests  of  various  attack  methods;  (5)  engineering  drawings  of  tha  HK  2 
Mod  7  high-security  hasp. _ 
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PHOTOGRAPHIC  DOCUMENTATION  Or  HIGH-SECURITY  SHROUDED  HASP  SYSTEM  DEVELOPMENT 
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CIVIL  ENGINEERING  LABORATORY 

NAVAL  CONSTRUCTION  BATTALION  CENTER 
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CIVIL  ENGINEERING  LABORATORY 

NAVAL  CONSTRUCTION  BATTALION  CENTER 
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CIVIL  ENGINEERING  LABORATORY 

NAVAL  CONSTRUCTION  BATTALION  CENTER 
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NAVAL  SEA  SYSTEMS  C0W1AND 
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LOCKS;  HASPS;  LOCK  ATTACK,  FORCED  ENTRY  NETHOOS;  LOCK  PARTS;  LOCK  TYPES; 
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Exhibit  3  provides  an  example  of  the  computer  file  listing  that 
results  from  the  entry  of  information  recorded  on  the  Data  Input  Sheet. 
Abbreviations  for  the  appropriate  fields  are  labeled  on  the  exhibit.  The 
user  can  easily  match  Data  Input  Sheet  fields  and  computer  output  formats. 
All  fields  except  Field  8  (Reserve  Field)  are  printed  as  output. 

3.3  PHYSICAL  SECURITY  DATA  MANAGEMENT  SPECIALIST 

r. 

Complete  implementation  of  the  data  input  procedures  of  the 
Physical  Security  Data  Management  System  would  be  facilitated  by  someone 
trained  specifically  in  the  fields  of  information  systems  and  library  and 
archival  science.  A  job  description  was  prepared  with  this  purpose  in 
mind. 


The  position  of  Physical  Security  Data  Management  Specialist  in¬ 
volves  the  interdisciplinary  application  of  library  science  technology,  in¬ 
formation  systems  technology,  and  archival  science  technology  for  the 
purposes  of  serving  the  in-house  RDTSE  needs  of  the  CEL  Physical  Security 
Laboratory  staff.  Specific  job  functions  include: 

1.  Performance  of  detailed,  routine,  and  clerical  library 
duties  pursuant  to  a  prescribed  set  of  methods  and  proce¬ 
dures  for  the  storage,  retrieval,  and  preservation  of 
technical  documentation  including  government  reports,  con¬ 
tractor  reports,  professional  books,  vendor  catalogs,  com¬ 
mercial  equipment  specifications,  government  specifications 
(including  military  specifications  and  standards),  technical 
data  sheets,  and  the  like,  related  to  physical  security. 

2.  Performance  of  detailed,  routine  and  clerical  library 
duties  such  as  cataloging,  coding,  summarizing,  cross- 
referencing,  annotating,  citing  and  abstracting  of  technical 
documentation. 
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Exhibit  3.  Example  of  computer  listing  of  dociment  after  data  entry 
and  report  generation. 
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set hod  of  Hutry;  builders  Harlvare;  Typas  of  Entry, 
Threats 

JlOIt 
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Provides  graphic  documentation  of  (1)  Installation 
procedures  for  heavy  steel  doors,  hollow  doers  and 
inward  opening  personnel  doors;  (2)  An  emergency 
forcible  entry  setood;  (3)  Hardware  coaponeats  of 
hasp/lock  systoes;  {«)  Tests  of  various  attack 
aethods;  (5)  engineering  drawings  of  the  .if  2  Rod  7 
high-security  hasp. 
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3.  Performance  of  detailed,  routine  and  clerical  archival 
duties  pursuant  to  a  prescribed  set  of  methods  and  proce¬ 
dures  for  accessing,  arranging,  describing,  preserv¬ 
ing,  using,  and  disposing  of  technical  archives,  including 
the  technical  documentation  described  in  items  1  and  2 
above . 

4.  Performance  of  data  input,  data  entry,  and  data  output  re¬ 
trieval  relating  to  automated  storage  and  retrieval  of  data 
from  on-line  or  batch  files  containing  bibliographies,  cita¬ 
tions,  abstracts,  and  related  summary  information  about  the 
principal  areas  of  physical  security  systems  and  physical 
security  technology  according  to  keywords.  The  performance 
of  these  functions  entails  the  use  of  general  knowledge  of 
the  steps  required  to  utilize  computerized  information  sys¬ 
tems  as  an  "end  user,"  i.e.,  the  knowledge  of  external 
steps,  processes,  and  user  procedures  rather  than  internal 
machine  steps,  language,  and  programs. 

In  developing  the  job  description,  consultations  were  sought  with 
the  Civilian  Personnel  Office  of  the  Defense  Nuclear  Agency.*  Position 
Classification  Standards  were  reviewed  as  prescribed  by  the  U.S.  Civil 
Service  Commission.  Three  different  positions  were  analyzed:  (1)  Library 
Technical  Series  (GS-141 1-4-6') ,  (2)  Computer  Aid  and  Technician  Series  (GS- 
335),  and  (3)  Archives  Technician  Series  C GS -1421-1-7) .  While  none  of 
these  positions  fits  precisely  the  kind  of  job  position  which  is  described 
above,  the  position  of  Physical  Security  Data  Management  Specialist  is  an 
"amalgam"  consisting  of  part  librarian,  part  computer  specialist  (or  infor¬ 
mation  systems  specialist),  and  part  archives  technician.  The  position 

*  Meeting  between  Mr.  Ron  Rothberg,  Civilian  Personnel  Office,  Defense 

Nuclear  Agency  (DNA)  and  Dr.  John  Caldwell,  Mission  Research  Corporation, 
at  DNA,  Washington,  D.C.,  12  May  1979. 
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defined  above  is  a  combination  of  the  job  functions  specified  in  the  Civil 
Service  categories  mentioned  above  and  most  accurately  approaches  the 
functional  requirements  of  the  CEL  Physical  Security  Laboratory  staff. 


SECTION  4 

USER  INSTRUCTIONS  FOR  REMOTE  DATA  ENTRY 


4.1  DATA  ENTRY  INSTRUCTIONS 

Once  a  Data  I up at  Sheet  has  been  completed,  the  information  can 
then  be  entered  into  the  computerized  Data  Management  System  for  on-line 
storage  and  retrieval.  Remote  data  entry  is  accomplished  through  use  of 
a  terminal,  either  a  cathode-ray  tube  (CRT)  or  printer,  with  a  standard  key¬ 
board.  For  purposes  of  illustration,  a  small,  portable  Texas  Instrument 
700  (TI  700)  electronic  data  terminal  has  been  used.  This  procedure  will 
be  updated  after  procurement,  installation  and  checkout  of  the  Data  General 
DASHER  TP2  terminal  at  the  CEL  Physical  Security  I.aboratory. 

As  noted  earlier,  data  entry  is  facilitated  through  use  of  a 
computer  program  known  as  WYLRUR  operating  on  the  UCSB  Itcl  AS/6.  WYLBUR 
is  an  on-line  text  editing  system  that  permits  direct  access  and  inter¬ 
action  with  data  files.  The  data  entry  procedure  is  structured  around 
WYLBUR  basic  commands. 

Exhibit  4  is  an  example  of  a  record  entry  from  a  TI  700  printing 
terminal  using  WYLBUR.  Where  appropriate,  lines  of  output  are  numbered 
and  circled  on  the  exhibit.  These  circled  numbers  match  similar  designa¬ 
tions  in  the  text  below  so  that  the  user  can  refer  to  the  example  as  he 
reads  the  procedure  step-by-step. 

To  access  WYLBUR,  once  the  terminal  is  connected  via  the  TI  700's 
acoustic  coupler  to  a  WYLBUR  telephone  line  at  the  UCSB  Computer  Center, 


Exhibit  4.  Example  of  record  entry  from  TI  700  terminal  using  WYLBUR 
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locks;  hasps;  lock  rttrck;  forced  entry  methods;  lock 
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FORCIBLE  ENTRY  METHOD;  ■ S 1  HARDWARE  COMPONENTS  OF 
HASP  LOCK  SYSTEMS;  <4>  TESTS  OF  VARIOUS  ATTACK 
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HIGH-SECURITY  HASP. 
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the  user  must  first  identify  himself.  This  process  is  called  a  "log-on." 

The  basic  information  required  for  WYLBUR  access  is  a  WYLBUR  account  num¬ 
ber,  a  user  name  and  a  user  password. 

The  first  step  is  to  press  the  red  return  key  on  the  TI  700  key¬ 
board.  The  user  will  then  be  prompted  by  the  query  "WYLBUR  ACCOUNT?"1  to 
which  the  user  should  reply  by  typing  his  identification  code.  The  over¬ 
printing  shown  on  three  exhibit  fields  is  deliberate  and  insures  that  no 
one  can  gain  unauthorized  access  to  the  user's  WYLBUR  files  by  casually 
examining  the  user's  account  number,  name  and  password.  Once  the  account 
number  and  name  are  entered,  the  return  key  should  again  be  pressed.  The 
next  prompt  will  be  "PASSWORD?"'’  to  which  the  user  should  reply  by  typing 
his  specific  password.  The  user  should  press  the  return  key.  The  next 
prompt  will  be  "COMMAND?"1  which  signifies  that  the  user  is  successfully 
logged  on. 

WYLBUR  has  a  "COLLECT"  and  a  "COMMAND"  mode.  For  purposes  here, 
the  user  need  only  be  concerned  with  the  "COLLECT"  mode.  This  will  collect 
and  save  the  text  as  it  is  entered.  When  the  user  is  prompted  with 
"COMMAND?"  he  should  type  in  "COLLECT"1  and  press  the  return  key.  The  "1" 
that  appears  indicates  that  WYLBUR  will  start  collecting  on  line  "1."  It 
is  at  this  point  that  the  user  can  start  to  enter  data  from  the  Data  Input 
Sheet.  For  ease  of  notation,  let  (RT)  indicate  the  return  key  and  (SP) 
indicate  the  space  key. 

‘‘Start  every  record  with  a  blank  line, 

5Start  with  the  zero  (0)  field  (accession  number)  on  the  Data  Input 
Sheet.  Type  ACNO  (SP)  and  the  number  (RT). 

*The  first  (1)  field  is  year.  Type  YEAR  (SP) ,  the  year  (SP) ,  the 
month,  if  appropriate,  and  (RT). 

7The  second  (2)  field  is  report  and  contract  number.  Type  RCNO  (SP) 
report  number;  contract  number  (RT). 
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'The  third  field  is  author,  type  AUTH(SP),  the  author(s)  (multi¬ 
ple  authors  are  separated  by  a  semicolon)  and  (RT). 

'The  fourth  field  is  the  title.  Type  TITI,  (SP),  the  title  (SP), 
and  page  count  in  parentheses  and  (RT). 

l#The  fifth  field  is  publisher.  Type  PUBl.  (SP),  the  publisher; 

(SP)  PO:  the  performing  organisation;  (SP)  CO:  the  controlling 
office;  (SP)  MA:  t he  monitoring  agency  (RT). 

1 1 1‘he  sixth  field  is  keywords.  Type  KF.YW  (SI’),  the  keywords, 
all  separated  by  semicolons  and  (RT). 

i The  seventh  field  is  annotation.  Type  NOTE  (SP) ,  the  appropriate 
words  and  phases,  separated  by  semicolons  and  (RT). 

1  ’ The  ninth  field  is  the  abstract.*  Type  ABST  (SP) ,  the  contents 
and  (RT). 

At  this  point  you  will  have  completed  t he  entry  for  one  record. 

To  enter  another  record,  skip  a  line  (RT)  and  begin  with  ACNO  again.  If  a 
field  on  a  Data  Input  Sheet  is  empty,  begin  immediately  with  the  next 
field  that  contains  information. 

When  the  data  entry  is  completed,  the  user  must  get  out  of  the 
"COLLECT"  mode  and  execute  the  commands  that  will  save  the  file  and  log  off 
the  system.  When  n  user  wishes  to  enter  more  data  at  a  later  date,  WYLBUR 
will  return  to  the  point  of  previous  termination. 

l'o  get  out  of  the  "COLLECT"  mode,  hold  down  the  key  marked  "CTRL" 
and  press  the  "P"  key.  This  will  interrupt  the  collection  and  prompt  with 
"CONWANP?" 1 "  At  this  point  the  user  may  return  to  the  "COLLECT"  mode  or  he 
may  log  off.  The  user's  reply  to  the  prompt  will  determine  the  result. 

*  l~he  eighth  field  is  the  reserve  field  which  is  not  currently  being  used. 
As  noted  on  page  19,  it  should  be  left  blank. 
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To  reserve  the  data  that  have  been  entered,  the  user  must  use  the 
"SAVE"  command  so  that  he  can  retrieve  and  add  to  the  file. 

When  the  user  completes  entry  of  a  record  (or  set  of  records)  and 
has  returned  to  the  "COMMAND"  mode,  he  should  type  SAVE  (SP) ,  name  of  the 
file*  (SP)  ON  (SP)  name  of  the  disk  pack  (RT) .  He  will  be  prompted  with 
"COMMAND?"  again.  To  this,  he  should  reply  "LOGOFF"  (RT).  WYLBUR  will 
then  ask  "OK  TO  CLEAR?"15  The  appropriate  response  is  "OK"  (RT) .  The 
user  is  now  off  the  system  and  the  work  is  reserved  until  he  wishes  to 
retrieve  it,  update  it,  etc. 

When  the  user  wishes  to  retrieve  and  add  to  the  file,  he  should 
follow  the  instructions  for  logging  on.  When  prompted  with  "COMMAND?"  he 
should  type  "USE"  (SP) ,  the  file  name  (SP)  ON  (SP)  name  of  disk  pack  (RT) 
(e.g.,  use  TMNO  ON  WYL1B2).  To  the  next  "COMMAND"  he  should  then  reply 
"COLLECT"  and  WYLBUR  will  return  to  the  point  of  previous  termination  and 
more  data  may  be  entered. 

4.2  WYLBUR  USER  INFORMATION 

Every  user  of  the  Physical  Security  Data  Management  System 
should  keep  a  permanent  record  of  basic  WYLBUR  user  information.  Table  1 
is  a  format  for  this  purpose.  It  includes  the  WYLBUR  direct  dial  number  at 
the  UCSB  Computer  Center  for  use  of  the  TI  700  terminal,  the  user's  WYLBUR 
account  number,  the  user's  WYLBUR  password,  and  the  user's  WYLBUR  file 
designation. 


*  Name  of  the  file  should  be  eight  characters  or  less. 
To  be  determined  at  a  later  date. 
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SECTION  5 

DESCRIPTION  OF  SYSTEM  OUTPUTS 


5.1  OVERVIEW  OF  SYSTEM  OUTPUTS 

The  instructions  thus  far  in  this  User's  Manual  have  addressed 
the  what  and  the  how  of  on-line  file  building.  This  section  addresses  the 
outputs  that  the  FAMULUS  computer  programs  can  produce  once  a  raw  data  file 
has  been  constructed. 

Figure  2  is  a  presentation  of  the  Data  Management  System  data 
output  procedure  in  more  detail.  It  expands  upon  the  overview  of  the  sys¬ 
tem  shown  in  Figure  1.  Currently,  there  are  one  Input  Pre-Processor  pro¬ 
gram  and  five  FAMULUS  programs  that  are  used  to  produce  system  outputs. 

The  flowchart  of  FAMULUS  programs  and  outputs  in  Figure  2  displays  the 
principal  program  capabilities  and  outputs  of  the  system. 

As  explained  in  Sections  3  and  4,  the  completion  of  Data  Input 
Sheets  and  the  accumulated  input  of  these  bibliographical  records  into 
WYLBUR  on-line  storage  result  in  the  creation  of  a  temporary  WILBUR  Raw 
Date  File.  The  Input  Pre-Processor  program  converts  this  raw  file  into  an 
expanded  Input  Data  File.  The  FAMULUS  Edit  Program  then  produces  an 
Edited  FAMULUS  File.  In  turn,  the  FAMULUS  Sort  Program  produces  a  Master 
CEL  FAMULUS  File. 


Application  of  three  additional  FAMULUS  programs  produces  the 
principal  batch  outputs  of  the  Data  Management  System.  The  FAMULUS  Galley 
Program  produces  the  Master  List  of  all  bibliographical  records  sorted  by 
accession  number. 
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The  FAMULUS  Index  Program  produces  the  Keyword  Index,  an  alpha¬ 
betized  list  of  all  keywords  and,  for  each  keyword,  a  list  of  all  biblio¬ 
graphical  record  numbers  in  the  Master  List  where  such  keywords  appear  in 
the  keyword  field  (Field  6  of  the  Data  Input  Sheet). 

The  FAMULUS  Count  Program  produces  two  statistical  reports:  (1) 
a  Keyword  Count  (subtitled  Vocabulary)  consisting  of  an  alphabetized  list 
of  all  keywords  and,  for  each  keyword,  the  absolute  and  percentage  fre¬ 
quencies  among  all  keywords,  and  (2)  a  Keyword  Count  (subtitled  Dictionary) 
consisting  of  a  list  of  all  keywords  sorted  by  frequency  from  highest  to 
lowest . 

Examples  of  a  Master  List  output,  a  Keyword  Index  output,  a  Key¬ 
word  Count  (Vocabulary)  output,  and  a  Keyword  Count  (Dictionary)  output  are 
shown  in  Exhibits  5-8,  respectively. 

The  FAMULUS  Search  Program,  when  implemented  in  FY  1980,  will  be 
capable  of  yielding  remote  terminal  displays  of  file  searches  as  well  as 
batch  search  reports  as  needed. 

Instructions  on  how  to  read  and  interpret  each  of  the  batch  out¬ 
puts  is  set  forth  in  the  subsections  below. 

5.2  MASTER  LIST 

Exhibit  5  is  an  excerpt  from  the  Master  List  showing  pages  51-53 
in  a  cascade.  Coinciding  with  the  example  of  the  record  shown  in  Exhibit 
3,  Record  Number  148  on  page  52  is  a  typical  record  output.  It  is  the 
computerized  version  of  the  Data  Input  Sheet.  All  fields  have  been  printed 
except  the  Reserve  Field  (Field  8  on  the  Data  Input  Sheet).  It  should  be 
noted  that  the  particular  record  shown  has  been  assigned  11  separate  key¬ 
words  or  phrases.  This  record  can  be  accessed  from  the  Master  List  by 
index  reference  in  the  Keyword  Index  to  any  one  of  the  11  keywords. 


Exhibit  5.  Master  list  utilization 
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5.3 


KEYWORD  INDEX 


Exhibit  6  shows  excerpts  from  the  Keyword  Index  and  the  Master 
List  outputs.  On  the  lefthand  side  of  the  exhibit  is  shown  a  cascade  of 
seven  of  the  pages  in  the  Keyword  Index  on  which  all  11  of  the  keywords  of 
Record  Number  148  appear.  On  the  righthand  side  of  the  exhibit  is  page  52 
of  the  Master  List  showing  Record  Number  148.  This  record  can  be  accessed 
by  referring  to  the  keywords  and  record  numbers  in  the  Keyword  Index  which 
appear  in  11  separate  entries. 

To  find  a  bibliographical  entry  (or  a  set  of  entries)  pertaining 
to- a  particular  keyword,  the  user  should  first  find  the  keyword  listed 
alphabetically  in  the  Keyword  Index  as  shown  in  the  example  on  the  left- 
hand  side  of  Exhibit  6.  One  of  the  keywords  associated  with  the  biblio¬ 
graphical  entry  dealing  with  high  security  shrouded  hasps,  shown  as  Record 
Number  148  on  the  righthand  side  of  the  exhibit,  is  Bpilders  Hardware  in 
the  alphabetical  sequence  of  keywords.  Opposite  the  keyword  entry  is  a 
list  of  Record  Numbers  including  Record  Number  148  which  is  circled.  By 
looking  up  Record  Number  148  in  the  Master  List,  the  user  can  find  the 
complete  bibliographical  entry  as  illustrated  on  both  Exhibits  5  and  6, 
i.e.,  the  full  citation  and  abstract  of  the  CEL  report  on  high  security 
shrouded  hasps.  This  same  report  could  have  been  accessed  by  10  other 
keywords  including  Doors;  Forced  Entry  Methods;  Hasps;  Lock  Attack; 

Lock  Parts;  Locks;  Lock  Technology;  Lock  Types;  Method  of  Entry;  and 
Types  of  Entry,  Threats.  Each  of  these  keywords  is  listed  on  the  other 
pages  shown  in  the  Exhibit  6  cascade. 

By  consulting  more  than  one  keyword  (as  appropriate)  the  user 
can  manually  reduce  (or  focus)  the  number  of  Record  Numbers  to  be  read 
on  the  Master  List  by  recording  on  a  separate  sheet  of  paper  only  those 
Record  Numbers  which  appear  under  two  (or  more)  different  keywords.  As 
long  as  the  list  of  Record  Numbers  is  not  too  long,  the  user  will  not  find 
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Keyword  Index  Excerpt  Master  List  Excerpt 


Keywords  (N=11):  Builders  Hardware;  Doors;  Forced  Entry  Methods;  Hasps;  Lock  Attack;  Lock  Parts; 
Lock  Technology;  Lock  Types;  Locks;  Methods  of  Entry;  Types  of  Entry,  Threats. 
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this  "intersection"  process  cumbersome.  If  the  number  of  keywords  is  long 
or  the  list  or  Record  Numbers  is  too  lengthy,  then  an  interactive  batch 
search  should  be  initiated  using  the  remote  terminal  search  procedure. 

The  scope  of  this  procedure  is  outlined  in  Section  6  below. 

5.4  KEYWORD  COUNT 

Exhibit  7  shows  a  cascade  of  the  current  list  of  keywords  presented 
alphabetically.  Opposite  each  word  is  the  absolute  number  of  times  the 
keyword  appears  in  separate  Master  List  records  followed  by  the  percentage 
of  this  frequency.  This  output  is  useful  in  two  respects.  It  provides  the 
user  with  a  complete  list  of  the  keywords,  or  the  controlled  vocabulary, 
of  the  Data  Management  System  by  which  records  can  be  accessed.  It  also 
provides  statistical  insight  into  how  frequently  specific  words  and  phrases 
appear  throughout  the  bibliographical  records  of  the  system. 

Exhibit  8  shows  a  similar  cascade  of  the  current  list  of  keywords 
arranged  by  frequency  from  highest  to  lowest.  Opposite  each  word  is  the 
absolute  number  of  times  the  keyword  appears  in  separate  Master  List  records 
followed  by  the  percentage  of  this  frequency.  For  example,  the  term 
"Control,  General,"  one  of  the  major  categories  in  the  Dataflow  Indexing 
Thesaurus,  is  currently  the  most  frequently  used  keyword  in  the  Data  Manage¬ 
ment  System  (N  =  51).  In  other  words,  the  keyword.  Control,  General  (re¬ 
ferring  broadly  to  physical  security  control  equipment),  appears  as  a 
keyword  entry  in  51  different  records  or  in  25  percent  of  the  current  records 
stored  in  the  Data  Management  System.* 


*  Currently,  there  are  201  separate  bibliographical  records  in  the  CEL 
Physical  Security  Data  Management  System. 
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Exhibit  8.  Keyword  count,  controlled  vocabulary  terms  listed  by  frequency 


SECTION  6 

SCOPE  OF  USER  INSTRUCTIONS  FOR  INTERACTIVE  BATCH  SEARCHES 


During  FY  1980,  one  of  the  planned  technical  efforts  is  the 
development  of  a  file  search  capability  in  an  interactive  batch  mode. 
Interactive  batch  in  this  context  refers  to  the  capability  interactively 
(1)  to  construct,  submit  and  manipulate  a  job  (in  this  case  a  search  of  the 
on-line  Master  CEL  FAMULUS  File),  which  is  processed  in  a  batch  mode  by  the 
I  tel  AS/6,  and  then  (2)  to  obtain  remotely  the  search  results  as  a  batch 
output,  eventually  through  using  the  Data  General  DASH  TP2  printing  termi¬ 
nal  at  the  CEL  Physical  Security  Laboratory  in  Port  Hueneme. 

Implementation  of  the  FAMULUS  Search  Program  will  create  this 
capability  for  the  CEL  Physical  Security  Data  Management  System  (see  Figure 
2,  supra) .  It  will  enable  much  more  specific  types  of  searches  according 
to  specific  keywords,  or  combinations  of  keywords,  and  production  of  much 
more  specific  outputs.  This  capability  will  be  particularly  useful  as  the 
number  of  records  in  the  Data  Management  System  increases. 

Once  the  Search  Program  has  been  tested  and  debugged,  a  set  of 
user  instructions  will  be  written  to  replace  this  text. 
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APPENDIX 

FAMULUS  USERS'  MANUAL 

NOTE:  This  manual  has  been  included  in  its  entirety.  It  is  computer 
output  from  the  Itel  AS/6  and  represents  the  most  up-to-date 
version.  It  contains  its  own  Table  of  Contents  and  has  its  own 


P  1  M  0  L  0  S 
Q  S  2  &  S  S  A  H  0  A  I 

University  of  California 
Santa  Ear  tar  a 

September  1977 

Fam-u-lus  (fan*  u  les),n.,pl.  -li  (-li)  ,  a  servant  or 
attendant,  esp.  of  a  scholar  or  a  magician.  [  t.  L] 

-the  American  College  Dictionary 
Random  House,  New  York 


Acknowledgement:  The  substance  of  this  manual  comes  from  the 
Famulus  Users  Manual  produced  by  the  computer  Center  at 
University  College,  London.  Their  manual  incorporated  much  of 
the  Famulus  Users  Manual  published  in  1969  by  the  Pacific 
Southwest  Forest  and  Range  Experiment  Station  at  the  University 
of  California  Berkeley  where  the  Famulus  system  originated. 

This  manual  was  edited  and  in  part  rewritten  to  describe  the 
University  of  California  Santa  Barbara  version  of  Famulus.  Bob 
Freeman  ana  Eyan  Werner  were  the  editors. 
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FORM  ARP 


Famulus  ii  an  integrated  set  of  FORTRAN  IV  programs  for 
inf ormatioti  retrieval.  Designed  with  the  individual  researcher 
in  mind.  Famulus  allows  the  user  to  create,  correct,  update,  sort 
and  merqe,  index,  search,  and  print  large  files  cf  information. 
The  programs  ire  simple  tc  use  and  costs  are  moderate. 

Famulus  originated  at  the  Pacific  Southwest  Forest  and 
Range  Experiment  Station  at  U.  C.  Berkeley.  The  system  was 
conceived  by  Theodore  B.  Yerke,  the  station  Librarian,  as  a 
"personal  documentation  system  for  research  scientists."  Mr. 
Yerke  worked  with  Robert  M.  Russell  in  the  development  of  a 
prototype  system.  In  July  1967  the  Research  Branch  of  the  Forest 
Service  Service  in  Washington  D.C.  agreed  to  support  development 
of  a  more  versatile  system.  The  IBM  360  conversion  from  the 
oriqinal  CDC  6400  programs  was  done  by  Jerry  fine  at  the 
University  of  California,  Los  Angeles  CCN  computer  center. 

Mr.  Alan  Shaw  and  others  at  University  College,  London 
(iJCL)  ,  added  extensive  new  features  to  Famulus  which  constitute 
about  cne-fourth  of  the  system  presented  in  this  nanual.  In  1973 
tney  generously  supplied  the  source  code  and  documentation  for 
Famulus  to  the  Sociology  Computing  Facility. 


Several  enhancements  and  modifications  tc  Famulas  have 
been  made  at  U.  C.  Santa  Barabara  by  Jonn  Fuuring  of  the 
Computer  Center,  and  others.  During  1977,  Bob  Freeman  and  Tom 
Andersen  created  a  brief  Programmers  Manual  that  describes  the 
Famulus  file  structure  and  gives  the  function  of  each  program  and 
subprogram.  They  also  added  many  comments  to  the  EDIT  program. 
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Famulus  is  an  i 
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n  storage  and  retrieval  system 
research  workers.  Traditional  systems 
with  filing  slips  can  te  converted  to 
the  benefits  obtained  will  repay  the 
ffers  various  information  retrieval 
tic  sorting  of  files  into  alphabetical 
ing  in  response  to  specific  reguests. 


The  system  is  sufficiently  general  in  design  to  encourage 
diverse  applications.  One  cf  the  most  obvious  is  the  maintenance 
c£  private  bibliographies  or  abstract  files.  In  a  small  library 
environment  Famulus  could  be  used  for  many  purposes,  from  keeping 
the  main  catalogue  to  maintaining  a  ’wants'  list  of  books  to  be 
obtained.  A  linguist  might  use  the  system  to  maintain  a 
dictionary  or  grammar  file. 

Faaulus  bandies  almost  any  kind  of  texts  except  large 
files  with  little  cr  no  regular  internal  structure.  It  is 
structure,  not  content,  that  matters.  This  manual  is  an  example 
of  a  file  which  is  not  suitable  for  Famulus. 


Although  primarily  designed  for  bibliographic 
applications.  Famulus  can  be  used  in  any  situation  where  "index 
cards"  would  be  useful.  Each  "citation",  or  record  in  Famulus  is 
lixe  a  3  by  5  index  card.  Within  each  citation  up  to  10  fields 
(analogous  to  lices  on  the  index  card)  are  available.  For 
example,  Faaulus  has  been  used  to  keep  track  of  a  large  record 
collection,  a  data  base  of  participants  in  community  training 
proqrams,  and  a  file  of  abstracts  on  laws  about  the  California 
coastal  area. 
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FILS  GBG ANIZ  ATIOM 


A  record  or  citaticn  is  the  fcasic  unit  of  information  in 
Famulus.  A  file  consists  of  an  unliaited  number  of  records.  The 
first  step  in  designing  a  Faaulus  file  is  to  decide  what  logical 
entity  in  the  data  a  record  should  represent.  For  instance,  in  a 
uiblioqraph ic  file  it  is  natural  to  consider  one  citation  or 
reference  to  be  a  record.  In  couple*  applications  it  aay  not 
always  be  obvious,  but  it  is  very  iaportant  to  establish  clearly 
from  the  outset  what  constitutes  a  record. 

The  record  itself  is  broken  down  into  fields.  Each  field 
is  qiven  a  name  or  label  (up  to  four  characters  long)  , 
appropriate  to  its  content.  Op  to  ten  fields  are  permitted.  The 
amount  of  information  in  a  field  may  vary  from  record  to  record 
or  from  field  to  field,  subject  only  to  the  restriction  that  a 
record  may  not  exceed  4000  characters  in  length.  Every  record  in 
a  file  must  have  the  same  field  structure. 

A  field  is  the  unit  of  information  used  to  sort  the  file 
into  alphabetical  order.  Therefore  the  field  divisions 
constitute  one  of  the  principal  methods  of  access  to  records  in 
the  file.  Consequently  the  number  of  fields  and  the  division  of 
the  information  in  the  record  into  fields  is  dependent  upon  the 
avenues  of  access  which  are  required  to  the  records.  See  the 
SORT  program  description  for  further  discussion  of  this  point. 

One  field  aay  be  designated  as  a  "descriptor  field."  In 
ordinary  fields  words  are  identified  as  such  oy  being  separated 
by  blanks  and  punctuation.  In  the  descriptor  field  whole  phrases 
may  be  treated  as  units  by  the  use  of  a  specified  delimiting 
character.  This  facility  caters  to  index  terms  consisting  of 
more  than  one  word. 


Example:  Hero  are  two  citations  from  a  bibliography. 

(The  choice  of  field  labels  is  completely  arbitrary) 


AUTH  Jeffries,  Ronald 
TITL  A  User's  Guide  to  QUIELE 
PUBL  Bulbs  Press 
YEAR  1984 

NOTE  A  fine  example  of  the  early  computer  era. 

Good  as  a  reference;  entertaining  bedside  reading. 

AUTH  Friedman,  Daniel  P. 

TITL  The  Little  Lispec 
PUBL  SRA  Associates 
YEAR  1914 
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The  Famulus  programs  are  summarized  below,  in  an  order 
which  reflects  our  notion  of  their  relative  importance. 


2DIT: 


SALLEY: 


SORT: 


SEARCH: 


OSSIFY: 


Creates  an  original  Famulus  file  from  Wylbur  or 
card  input,  and  modifies  existing  files. 

Produces  a  printed  copy  of  a  Famulus  file.  It  has 
four  output  formats;  the  default  format  which  does 
uot  print  field  labels  and  does  not  start  new  line  for 
each  field;  the  /PRINT  BY  FIELDS/  format  which  labels 
each  field  and  starts  each  on  a  new  line;  the  /PRINT 
BY  SUBJECTS/  format  which  does  not  print  field  labels, 
and  produces  left  and  rijht  justified  margins;  and  the 
/TABS/  option  which  prints  the  fields  as  columns 
between  user  selected  tabs.  /TAES/  is  most  useful 
with  very  short  fields.  A  GALLEY  run  can  specify 
selected  records  and  fields  to  be  printed,  thus  a  file 
with  ten  fields  per  record  may  be  listed  with  only 
three  fields  appearing.  The  order  of  the  fields  may 
also  be  altered  in  the  output. 

Alphabetically  sorts  the  records  in  an  existing 
Famulus  file  on  any  given  field  and  puts  the  sorted 
results  in  an  output  file.  file  is  not  destroyed. 

Provides  for  computer  searching  of  a  Faiulus  file. 
Output  can  be  a  printed  listing  of  all  file  entries 
which  meet  the  selection  criteria,  or  a  listing  of 
only  the  record  numbers  of  those  entries.  with 
appropriate  Job  Control  Language  (JCL)  and  use  of 
the  /WRITE  TAPE/  control  statement,  SEARCH  will 
produce  an  output  file. 

For  various  reasons  one  may  need  to  convert  a  Famulus 
file  bach  to  statement  form.  Ossify  does  this  with 
any  internal  Famulus  file  as  input  and  a  statement 
image  file  as  output.  With  appropriate  JCL  puched 
statement  output  may  be  obtained. 

Takes  two  sorted  Famulus  files  and  outputs  a  merged 
copy.  The  two  files  to  he  merged  must  have  the  same 
number  of  fields  per  record,  though  the  fields  can 
have  different  names.  Each  file  must  be  sorted  on  its 
first  field. 


MERGE: 


Famulus  - 


MULTI FLY: 


INDEX : 


COUNT: 


VOCAB: 


KEY: 
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In  some  cases  the  records  a  file  may  be  sorted  on  a 
field  which  has  multiple  entries.  A  printout  of  the 
file  would  not  readily  demonstrate  which  records 
contained  a  particular  field  entry,  as  a  given  record 
would  only  appear  once,  under  the  first  item  listed 
in  the  field  on  which  the  file  was  sorted.  To  allow 
for  this,  MULTIPLY  produces  an  output  file  with 
multiple  record  entries  generated,  one  for  each  item 
in  the  specified  field.  If  we  wished  to  have  a 
listing  of  our  file  by  Keyword,  and  a  given  record  had 
three  Keywords,  we  could  have  MULTIPLY  produce 
duplicate  entries  of  the  record,  one  for  each  of  the 
three  terms  in  the  specfied  field.  If  this  file  was 
printed  out  we  would  find  the  given  record  in  three 
different  places. 

Produces  an  alphabetized  index  of  a  Faxulus  file.  The 
index  can  reference  one  or  more  fields  of  the  record. 
One  typical  use  might  be  to  index  a  descriptor  or 
Keyword  field. 

For  any  specified  field  or  fields  within  a  Pamulus 
file  COUNT  produces  a  vocabulary  listing  with 
frequency  cf  occurence  noted  for  each  word.  It  is  a 
useful  step  in  the  development  of  a  controlled 
vocabulary  Keyword  thesaurus. 

Basically  does  the  same  thing  as  COUNT,  but  does  not 
qive  frequencies.  In  almost  every  case,  COUNT  would 
be  preferable  to  7CCAB.  The  exception  might  be  an 
extremely  large  file,  or  a  file  with  words  longer  than 
the  maximum  allowed  by  COUNT. 

KEY  allows  ’automatic’  keywording.  It  scans  a 
specified  input  field  and  for  each  ncn-trivial  word  or 
term  it  inserts  the  same  into  a  specified  Keyword 
field.  One  problem  is  that  often  the  most  useful 
key  words  are  'added  Keywords',  that  is.  Keywords 
which  specify  the  subject  of  the  entry  but  do  not 
necessarily  occur  in  the  title.  K2I  does  allow  for 
synonyms  whereby  a  number  of  input  terms  can  be 
considered  equivalent. 


KWIC: 


Produces  a  Keyword-in-context  index 
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FAMULUS  AND  WYLBUR 


Famulus  files  may  be  created  on  iiylbur  and  submitted  to 
tne  central  computer  for  famulus  operations  with  far  greater  ease 
than  cards  allow.  storage  of  Famulus  data  in  Wylbur  files  allows 
quick  reference  to,  and  modifications  of,  the  card  (or  Wylbur) 
image  cata. 


It  is  important,  however,  to  distinguish  between  data  in 
external  form  (card  or  Wylbur  image)  and  its  representation  on 
disk  or  tape  as  a  Famulus  file.  The  distinction  is  not  in  the 
storage  medium,  for  no  such  medium  is  any  less  external  than 
another;  however  from  the  point  of  view  of  the  Paaulus  system, 
internal  files  are  those  in  the  form  in  which  data  is  stored  and 
processed.  EDIT  is  the  only  Famulus  program  which  accepts  card 
imaqe  data.  The  ether  frograms  only  operate  upon  the  files 
created  oy  EDIT. 

Just  as  data  in  external  form  is  not  readable  by  the 
Famulus  system,  internal  Famulus  files  are  not  readable  by  other 
programs,  and  are  not  suitable  for  direct  transfer  cut  of  the 
system.  That  is  to  say.  Famulus  cannot  operate  on  a  Wylbur  file 
except  to  convert  it  into  internal  format  via  the  EDIT  program. 
Likewise,  internal  Famulus  files  are  meaningless  to  Wylbur.  The 
OSSIFY  program  converts  files  from  the  internal  Famulus  format  to 
a  form  that  can  be  edited  on  Wylbur. 
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PHEPASINd  DATA  FOR  FAMULUS 


Existing  machine- readable  data  files  can  sometimes  be 
converted  by  a  special  purpose  program  to  Famulus  input  format. 
Otherwise  data  must  be  punched  on  cards,  or  keyed  at  a  terminal. 

IngMt-laJC-MJ* 

Field  labels  are  written  in  columns  1-4  of  the  first  line 
in  a  field.  Continuation  statements  for  the  field  dc  not  carry 
labels.  Actual  text  of  the  record  begins  in  column  6  and  can 

continue  through  column  80.  if  it  is  necessary  to  continue  onto 
another  statement,  end  the  first  statement  after  a  word  or 

sentence  in  any  column  and  simply  start  in  column  6  of  the  second 
statement.  Famulus  will  append  the  continuation  line  to  the 
first,  inserting  no  blanks  after  hyphens,  one  blank  after 
letters,  and  two  blanks  after  periods,  commas,  exclamation 
points,  question  marks,  semicolons,  and  colons. 

The  fields  in  a  record  must  be  in  the  correct  order, 
otherwise  the  record  will  be  rejected.  Fields  may  be  omitted, 
however,  since  not  every  record  in  a  file  will  require  all  the 

allowable  fields.  In  this  case  a  statement  containing  the  field 

lanel  is  not  required. 

Each  record  is  followed  by  a  blank  line  which  separates  it 
from  the  next  record.  If  the  blank  line  is  left  cut,  the  second 
record  will  be  run  on  tc  the  first  and  both  will  be  rejected. 
The  last  record  in  the  input  deck  should  also  be  followed  by  a 
blank  line. 

Preparation  of  uprer  and  lower  case  text  at  a  Wyibur 
terminal  should  present  no  problems.  For  alternate  methods  of 
introducing  lower  case  text  (such  as  on  cards)  see  Appendix  C. 
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Belov  are  examples  c£  the  exact  format  for  inputing 
broil oqraphic  citations  for  Famulus.  Note  that  a  blank  line  is 
inserted  between  each  citaticn  or  record. 


columns : 

12  34567891  12345678921 2345o7 8 931 234567894 123456? 89 51 234567896  123456789 
**♦♦♦♦♦ 

AUTH  BERKELEY,  EDMCND  C. 

TITL  1  BE  COMPUTER  REVOLUTION 

PUBL  GARDEN  CITY,  NEW  YORK:  DCUBLEDAY  AND  CO . , INC  . ,  1  962 
YEAR  1562 

KS  Y  Vi  ECO  K  CITATION 
CALL  2  699  B4 

AbST  EXAMPLE  CITATICN  FOR  A  EOOK. 

AUTH  ANONYMOUS 

TITL  "A  CITY  WHERE  COMPUTERS  WILL  KNOW  ABCUT  EVERYBODY*' 

PUBL  O.S.  NEWS  AND  WORLD  HEECBT,  MAY  15,1967  PG.  78-7S 
YEAR  1967 

KE  Y  v  NEWSPAPER  CITATICN,  MAGAZINE  CITATION,  ANONYMOUS,  NO  AUTHOR 
CALL  2  1.  G 5  4 

ABST  EXAMPLE  OF  CITATICN  FOR  NEWSPAPER  OF  MASS  CIRCULATION  MAGAZINE. 
ALSO  ILLUSTRATES  THE  USE  OF  A  CC NTI NU ATI CN. 

AUTH  SOMEBODY,  FRED.  E.,  AND  JENIFFEB  CHUMASH 
TITL  "THE  ARTICLE  TITLE  IS  IN  yUOTES" 

IN  RCN  LASTNAMZ  (ED),  THE  TITLE  OF  THE  3CCK 
PUBL  BADROCK,  N.J. :  EXAMPLE  PUBLISHING,  INC.,  1984 
YEAR  1984 

KEYW  ARTICLE  IN  COLLECTION  CITATION,  USE  CF  'IN'  FIELD 
CALL  22  99  A  1 0  1 

ABST  EXAMPLE  OF  CITATION  OF  AN  ARTICLE  IN  A  BCOK  THAT  IS  A  COLLECTION 
OP  ARTICLES  OR  INDIVIDUALLY  AUTHORED  CHAPTERS. 
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The  operation  of  Pamulus  programs  is  controlled  by  program 
coutrol  statements.  They  are  used  for  various  purposes;  e.g.  to 
inform  Famulus  of  the  names  of  files  or  fields,  to  select 
portions  of  a  file  for  processing,  to  reguest  particular  printed 
output  formats,  and  many  ether  varied  functions.  Some  control 
statements  are  specific  to  certain  programs,  but  many  are  used  by 
more  than  cne  program.  An  effort  was  made  at  UCL  to  generalize 
the  control  statements  as  far  as  possible,  to  achieve  greater 
flexibility  and  more  powerful  facilities,  hopefully  without 
changing  the  philosophy  of  the  original  system  toe  much.  A  chart 
of  the  control  statements  available  to  each  program  is  given  in 
Appendix  A. 

All  control  statements  are  a  set  of  upper  case  iceywords 
recognized  by  Famulus,  enclosed  in  slashes  and  written  beginning 
in  column  one  onwards.  Some  control  statements  consist  of 
nothing  more  than  this: 

/ORIGINAL/ 

/WRITE  TAPE/ 

/PUNCH/ 

/ NUflBERS/ 

/PRINT  BY  FIELDS/ 

/ERINT  EY  SUBJECTS/ 

/FLAGS/ 

The  information  conveyed  by  these  statements  is  essentially  of  a 
yes/no  nature.  The  majority  of  control  statements,  however, 
require  provide  particulars  cf  the  action  desired,  in  the  form  of 
text  which  follows  the  second  slash  of  the  statement,  though  not 
necessarily  immediately.  If  the  whole  text  does  not  fit  on  one 
line  it  can  be  continued  on  the  next  anywhere  from  column  one 
onwards.  The  text  of  most  statements  is  enclosed  in  parentheses: 
Refer  to  Appendix  A  for  a  summary  of  control  statement  syntax. 

/FIELDS/  (AUTH, TIT  I,  PUB,  DATE) 

/DELETE/ ( 3 ,  15-19,  46-68,101) 

/SELECT/  (1-500,  575-690) 

There  are  no  enclosing  parentheses,  however,  on  the  follcwing: 

/ID /PARTS  IN  VENTOR I 
/NEW  ID/  CLASSIFIED  INDEX 

/SEARCH/  SOIL  STABILITY  6  (EHCSICN  )  SLIDES) 

/VQC  ABU  LARY/A*THE*IN*SCIL,  ST  A  EILITY  ,  EROS  ION 
/SYNONYilS/  ZROSION  =  SLIDES,DOSI 
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The  use  of  the  control  statements  is  described  further 
under  each  separate  program,  but  it  is  appropriate  at  this  point, 
to  introduce  a  few  statements  which  are  common  tc  acst  of  the 
famulus  programs. 


Internal  files  are  always  labelled  with  an  identifier. 
When  a  file  is  used  as  input  to  a  program  Famulus  checks  the 
identifier  written  on  the  tape  with  the  text  of  the  /ID/ 
statement.  If  they  fail  to  match  an  error  message  is  produced 
and  the  proqraa  terminates. 

The  identifier  may  be  up  to  100  characters  in  length. 
Blanks  before  and  after  the  file  name  are  ignored.  Write  up  to 
column  80,  and  if  required  continue  in  column  one. 

Zvery  Famulus  job  needs  an  /ID/  statement,  and  it  must  be 
the  first  control  statement  to  appear. 

/NEW  ID/ 

Whenever  a  operation  on  an  existing  file  produces  a  new 
file  the  identifier  with  which  the  new  file  is  labelled  is  taken 
from  a  /NEW  ID/  control  statement.  The  new  identifier  is  punched 
after  /NEW  ID/  in  the  same  way  as  on  the  /ID/  statement.  If  this 
control  statement  is  not  supplied  the  /ID/  statement  is  used 
instead,  which  means  that  the  output  file  is  labelled  the  same  as 
the  input  file  by  default. 

In  most  programs  the  text  from  the  /NEW  ID/  statement  is 
printed  as  a  title  on  the  first  line  of  every  page  after  the  page 
number.  Even  when  no  output  file  is  being  made  this  control 
statement  is  still  useful  for  entitling  the  printed  output. 
Aqain,  the  default  title  is  taken  from  the  /ID/  statement. 

znasiz 

Field  labels  may  be  up  to  four  characters  in  length,  must 
begin  with  an  alphabetic  character,  and  the  remaining  characters 
must  be  either  alphabetic  oc  numeric.  Lower  case  characters  and 
special  characters  such  as  punctuation  are  not  allowed. 

PUBL  (legal  field  label) 

PUB.  (illegal  field  label) 

The  text  of  this  statement  consists  of  a  list  of  field 
labels  separated  by  commas,  the  whole  enclosed  in  parentheses. 
The  list  supplies  three  kinds  cf  information:  the  number  of 
fields,  the  order  in  which  they  occur  in  the  record  and  their 
names.  This  information  is  used  in  different  ways  according  to 


Famulus 


A  Documentation  System  (Program  Control  Statements)  10 


the  requirements  of  each  program.  For  instance,  in  EDIT  the, 
/FIELDS/  statement  is  used  to  define  the  full  record  structure 
for  the  output  file,  in  GALLEY  it  is  used  to  define  ihe  number 
and  order  of  the  fields  to  be  printed;  in  SORT  it  defines  the 
sort  key,  in  SEARCH  and  COUNT  it  indicates  the  field  or  fields  to 
be  searched  or  counted;  and  in  MULTIPLY,  where  only  one  field 
lanel  is  permitted  in  the  statement,  this  information  defines  the 
field  on  which  the  file  is  to  be  multiplied. 

/DESCRIPTOR  FIELD/ 

The  INDEX  program  is  designed  to  work  cnly  on  the 
descriptor  field  of  a  file.  Descriptors  are  subject  headings  or 
index  terms  which  often  consist  of  more  than  one  word.  Therefore 
within  the  descriptor  field  descriptors  are  separated  by  a 
delimiter  or  break  character  and  may  consist  of  any  character 
strmq  including  blanks  and  punctuation  apart  from  the  break 
character. 

Other  proqrams,  such  as  SEARCH,  COUNT,  MU1TI PLY,  and  KEY, 
also  recognize  the  descriptor  field  and  regard  its  contents 
differently  from  ether  fields.  when  working  on  the  descriptor 
field  these  programs,  like  INDEX,  identify  items  by  means  of  the 
break  character,  and  words,  delimited  by  blanks  or  punctuation, 
are  th<  basic  items  in  other  fields. 


Cnly  one  field  nay  be  a  descriptor  field  at  any  one  time. 
There  is  no  obliqaticc  tc  designate  a  descriptor  field,  but  once 
defined  the  identity  of  the  descriptor  field  becomes  part  of  the 
information  carried  in  the  file  like  the  identifier  or  fields 
information,  and  there  is  no  need  to  include  the  /DESC RIPTOR 
FIELD/  statement  again.  This  information  cannot  be  altered  on  an 
input  tape,  Dut  a  /DESCRIPTOR  FIELD/  statement  will  temporarily 
redefine  the  descriptor  field  during  the  execution  of  many  of  the 
Famulus  programs,  reverting  afterwards  to  the  field  defined  on 


the  file.  If  an  output  file  is  produced,  the  descriptor  field 
may  be  permanently  redefined  cn  the  output  tape  by  the 
/DESCRIPTOR  FIELD /  statement,  otherwise  the  input  file  descriptor 
field  is  carried  over  by  default. 

The  delimiter  or  break  character  is  taken  as  comma  by 
default,  and  this  information  is  not  carried  on  the  file.  If  the 
break  character  used  is  net  a  comma,  therefore,  the  /DESCRIPTOR 
FIELD/  statement  will  be  necessary  every  time. 

The  text  after  the  /DESCRIPTOR  FIELD/  statement  consists 
of  a  field  name  in  parentheses  followed  by  a  break  character, 
also  in  parentheses.  The  break  character  is  not  optional,  even 
if  it  is  comma;  its  omission  causes  some  programs  to  Kilfunction. 
Tne  field  name  must  be  one  cf  those  defined  on  the  input  file,  or 
on  the  /FIELDS/  statement  if,  as  may  be  the  case  with  EDIT, 
there  is  no  input  file.  Any  character  may  serve  as  the  break 
character. 
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This  control  statement  is  jsed  to  select  records  for 
processing  out  of  the  input  file.  The  text  consists  of  a  list  of 
record  numbers  not  necessarily  in  ascendinq  order  separated  by 
commas,  the  whole  list  beinq  enclosed  in  parentheses.  Instead  of 
a  number  an  item  in  the  list  may  consist  cf  a  rauqe  of 
consecutive  numbers,  indicated  by  separating  tie  first  and  the 
last  in  the  ranqe  by  a  dash.  Text  length  for  this  statement  is 
limited  to  100  numbers,  where  a  sequence  counts  as  two  numbers, 
irrespective  of  its  lenqth. 

This  statement  rs  always  optional.  If  it  is  omitted,  the 
whole  file  will  be  processed  unless  it  exceeds  103,000  records. 
For  processinq  to  continue  beyond  this  limit  an  appropriate 
/SELECT/  statement  is  required. 
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EDIT  aoaU':i  an  internal  Famulus  film  from  card  or  wylbur 
mpat  and  writes  the  file  into  magnetic  tapo  or  disc  storage. 
In  this  case  the  /I U/, / FI  ELDS/  and  /DESCRIPTOR  rih'LD/  control 
statements  provide  the  name  of  the  file,  tie  list  of  field 

labels,  and  t  ho  name  of  the  descriptor  field,  if  any,  and 

this  information  is  written  in  the  output  tile  (FTD2F001) 
preceding  record  entries.  An  /ORIGINAL/  control  statement 
aust  be  present  to  indicate  that  an  original  file  is  being 
created  and  that  there  is  no  input  file.  The  last  control 
statement  east  be  /CITATIONS/,  followed  by  the  data  for  EDIT. 

The  card  image  input  can  immediately  follow  the 
/CITATIONS/  card  or  it  can  be  stored  as  a  separate  tile.  If  the 
EDIT  program  tiuds  no  data  following  the  /CITATIONS/  control 
statement,  it  opens  FT0JF001  and  tries  to  read  ciations  there. 
Note  that  the  file  on  FTdJFOOl  must  have  the  following 
characteristics:  KSCK3«Kti  and  lflECI«Sd.  If  this  file  was  saved 

from  wvibur,  the  command  "CAUC”  or  "LK ECl * Rd"  will  produce  tho 

proper  tile  characterise  icr .  (If  cn«>  of  these  was  not  used,  you 

will  get  strange  error  messages!) 


Once  the  file  has  been  created  fresh  dat a  say  be  added  by 
emitting  the  /ORIGINAL/  control  statement  and  supplying  the  file 
as  input,  using  the  ddname.  FTJlFdOl,  and  PISi'»GLP  (indicating 
that  the  file  already  exists).  Tho  file  is  copied  to  an  output 
file  ( FT0*F  00  1)  ,  and  The  new  data  is  added  to  the  end  of  the 
original  data.  'Corrections  to  th«  input  file  may  be  made  via 
/REPLACE/  and  /DELETE/  control  statements  as  it  i^s  being  copied. 

Adding  new  data  to  a  large  sorted  operational  film  mmy 
call  for  a  more  complicatmd  proemdurm.  Thm  new  data  can  be 
written  onto  a  teaporacy  file  and  then  sorted  into  the  sane  order 
before  being  merged  with  the  nastor  file.  This  is  sere  efficient 
than  afdinq  new  records  to  the  saster  and  sorting  the  whole  file 
after  every  update. 


If  no  additions  arm  tc  be  made  the  /CITATIONS/  control 
stateaent  is  oaitted,  and  operations  arc  liaitmd  to  changes  to 
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the  INPUT  file.  /NEW  ID/  renames  the  output  file.  New  field 
names  may  follow  a  /FIELDS/  statement  in  order  to  produce  new 
field  labels  in  the  output  file. 

Only  EDIT  cau  change  field  names  in  this  way;  all  the 
other  programs  require  the  labels  on  the  /FIELDS/  statement  to 
match  the  input  tape.  Note  that  EDIT  cannot  ce  used  like  SORT  to 
chanqe  the  order  of  the  fields  in  the  record.  Nor  can  the  number 
of  fields  be  changed.  It  is  wise,  therefore,  when  creating  the 
file,  to  declare  more  fields  than  are  immediately  required  using 
dummy  names  which  can  be  changed  later  when  the  need  for  another 
field  arises.  For  example,  a  spare  field  may  be  needed  as  a  key 
field  for  the  KEY  program.  Dummy  fields  incur  virtually  no  time 
or  space  penalty  and  can  be  ignored  dunug  data  preparation. 


Deleting  records 

Complete  records  are  deleted  from  the  file  by  the  /DELETE/ 
control  statement,  similar  in  syntax  tut  opposite  in  semantics  to 
/SELECT/.  A  list  of  up  to  500  record  numbers  is  acceptable  to 
/DELETE/.  If  twe  numbers  in  the  list  are  separated  by  a  hyphen 
instead  of  a  comma  they  represent  a  range  of  records  beginning 
with  the  first  and  ending  with  the  second. 


CopjLectisns 

Corrections  are  made  by  means  of  the  /REPLACE/  statement. 
Up  to  100  corrections  are  permitted  in  each  run  of  EDIT. 
/REPLACE/  occurs  only  once,  and  is  followed  by  the  details  of 
each  replacement  in  free  format.  Every  change  requires  four 
pieces  of  information:  the  record  number,  in  parentheses,  the 
name  of  the  field  which  is  to  be  changed,  also  in  parentheses, 
the  text  which  is  to  be  replaced,  and  the  new  material  which  is 
to  take  its  place.  Three  asterisks  are  used  to  delimit  the 
beqinninq  of  the  first  text,  the  end  of  the  first  and  beginning 
of  the  second  text,  and  the  eua  of  the  second,  respectively. 


/REPLACE/  ( 1)  (AUTH)  •  SMITHH*SMITH* 

(2)  (TIT  L)  *  MAT H IM  ATI  C  AL*M  AT  HEMATIC  AL* 

(5)  (ABS'I )  ♦♦THIS  PAPER  INCLUDES  A  DISCCSSICN  CF 
CURRENTLY  IMPLEMENTED  LINEAR  PROGRAMMING  TSCHN 
IWUES  AVAILABLE  FC8  THE  IBM  360.* 

{  120-  12  7)  (AUTH)*MACPHEE  ,*  MAC  PHEE  ,* 


ramul us 


A  Ducutenta tiot  System  (SOU) 


14 


These  lines  change  "SMITBH"  to  "SHITB"  iu  the  author  field 
of  record  1,  "MATHIM  ATICAL**  to  "MAT  KEN  ATI  CAL"  in  the  title  field 
of  record  2,  add  an  abstract  to  record  5,  and  change  author's 
name  from  "MACPHEE"  to  "SAC  PBEE"  in  eight  consecutive  records. 

When  numerous  corrections  are  to  be  Bade  the 
one-stat eaent- per-  correcticn  approach  is  most  convenient.  If 
tne  text  extends  beyond  column  83  it  is  continued  in  ccluan  one 
of  another  statement.  The  corrections  may  also  be  punched  as  a 
strinq,  in  free  foraat. 

/EEPL ACE/  ( 1)  (AUTH)  *INCCBHEC1  INPCBMATICN*CCBE£ 

CT  1MF0EMATICN*  (2)  (TITL)  ** IN FOBM ATION  TO  BE  AD 
DED*  (5)  (AUTH)*MATERIAL  10  BE  DELETED**  (9)  ( ABS) 

*  *  NEW  MATERIAL  TC  BE  ADDED*  (25)  (A  tlTH)  *  I NCOBBEC 
T*C0RRECT*  (25)  (TITL)  *1 NCORRECT*CQBRECT* 


Corrections  should  always  be  made  to  the  latest  version  of 
a  file,  and  the  corresponding  most  up-to-date  listing  should  be 
used  tc  look  up  the  numbers  of  the  records  to  be  changed. 
Corrections  need  not  be  input  in  ascending  order  of  record 
numbers.  The  program  makes  one  pass  through  the  input  file, 
taking  each  record  in  turn  and  scanning  all  corrections  to  find 
any  that  apply  to  it.  The  cited  field  is  then  scanned  for  the 
text  tetween  the  first  and  second  asterisk,  and  this  is  replaced 
by  the  text  between  the  second  and  third  asterisk.  The  leugth  of 
the  two  texts  need  not  be  the  same. 


Pslst,iflas_aDd._additions  to  a  field 

Deletions  can  be  made  by  puttiug  the  striae  to  be  deleted 
between  asterisks  and  punching  the  third  asterisk  immediately 
after  the  second,  which  means  that  the  replacement  text  is  a 
null  cr  empty  strinq.  Material  can  be  added  to  the  end  of  a 
field  by  punching  two  asterisks  before  and  the  third  after  it, 
which  means  that  a  null  string  is  deleted. 

Sufficient  information  must  be  quoted  to  uniquely  identify 
the  text  to  be  replaced.  If  a  word  occurs  more  than  once  in  a 
field  and  you  wish  to  chanqe  only  cne  occurrence  of  it,  include 
enouqh  preceding  or  following  characters  to  distinguish  the  two 
occurrences. 

If  tnere  are  two  changes  t c  be  made  within  the  same  field 
with  considerable  information  separating  them,  make  two 
replacement s  quoting  the  record  number  and  field  label  each 
time. 
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Lower-case  flag  characters 

To  facilitate  corrections  to  files  of  upper  and  lower  case 
text,  use  either  Wylbur  to  prepare  the  replacement  data  or  the 
riaq  characters  described  in  Appendix  C.  If  flags  are  used,  the 
/FLA3S/  statement  must  precede  the  /REPLACE/. 


££ihlJLfi_outjBut 

The  /PRINT/  statement  is  used  to  control  the  printing  of 
the  file.  The  text  of  this  stateaent  is  similar  to  /SELECT/:  a 
list  of  up  to  100  numbers  identifying  records  or  sequences  of 
records  to  be  printed.  The  record  numbers  correspond  to  the 
output  file.  If  nc  /PRINT/  statement  is  supplied  the  default 
actions  am  as  follows:  records  from  an  input  file  are  not 
printed  unless  changes  are  made  in  them  and  on  data  input,  and 
with  a  /CITATIONS/  statement,  only  the  first  1000  records  are 
printed  au t omat icd 1 ly .  Printing  can  be  suppressed  altogether  by 
/PR  INI  /  (0)  . 

Records  ate  printed  with  explicit  field  labels  as  in 
dALLEY  when  the  /PRINT  EY  FIELDS/  statement  is  used.  This  is  the 
most  convenient  format  for  making  corrections,  and  no  other 
format  is  permitted. 

The  maximuc.  number  ot  characters  printed  cn  a  line  is  12  8, 
which  is  also  the  default.  The  /WIDTH/  statement  reduces  the 
line  width  to  a  number  specified  in  parentheses  after  the 
/w'  IDT H/  . 

/WIDTH/  (70) 

This  statement  reduces  the  line  width  to  70  characters.  The 
minimus  width  is  20  characters.  Faxulus  never  ends  a  line  in  the 
middle  of  a  word,  unless  the  word  is  too  long  to  fit  on  a  line. 
Lines  are  left  with  spaces  at.  the  righthaud  side  if  net 
completely  filled. 


lifflii4tign_s_on_EDIl^  _anfl._UEIT 

EDIT  allows  a  maximum  of  100  corrections  per  run,  and  a 
maximum  of  dOO  characters  per  correction.  If  either  limit  must 
be  exceeded,  use  EDIT's  big  brother,  LEDIT,  which  allows  as  many 
as  1000  corrections  of  up  tc  4000  characters  per  run. 
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/ID/DR  AC UNCULUS  BIELICGRAPHY 

/FIELDS/(AOTH,TITL,JBN  L ,  PAG  N,YEA£,1ANG,SBCZ,KEYH,ELNK,  ABST) 
/DESCRIPTOR  FIELD/  (KEYU)  (,) 

/ORIGINAL/ 

/CITATIONS/ 

/WIDTH/  (70) 

/REPLACE/  (1)  (AUTH) *SMITHH*SrtITH* 

12)  (T  ITL)  *NA1HIHA1ICAL*HAIHEHATIC  AL* 

/DEIETE/(7, 100,  50-63) 

/PRINT/ (7,100,50-63) 


> 
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OSSIFY  creates  a  file  of  card  images  from  any  Faaulus  file. 
The  new  file  will  be  in  standard  Faaulas  input  format,  with  the 
field  labels  established  by  the  aost  recent  EDIT  run.  The 
principal  use  is  to  produce  "backup"  files  in  case  the  Faaulus 
file  cn  disk  or  tape  is  damaged  or  coapletely  lost,  cr  to  aake 
changes  on  Wylbur. 

Under  certain  conditions,  it  nay  be  less  expensive  to  use 
OSSIFY  for  the  correction  of  a  badly  organized  file,  particularly 
if  the  file  has  long  fields,  such  as  abstracts  or  text-storage 
which  aust  be  deleted  or  changed  extensively.  For  instance,  if 
for  sone  reason  aany  citations  had  incorrect  abstracts,  or  if  the 
abstracts  were  written  with  the  wrong  citation,  or  if  several 
fields  in  each  citation  had  errors,  it  would  be  far  aore 
economical  to  have  the  faulty  records  put  into  statement  image 
form  cn  disk.  Then,  after  xaking  the  corrections  on  this  file 
with  Wylbur  and  deleting  the  original  citations  from  disk  or 
tape, an  additions  run  would  re-add  the  corrected  citations  to  the 
disk  or  tape 

The  /SELECT/  statement  indicates  the  records  to  be  written 
onto  disk.  The  record  numbers  should  directly  follow  the 
/SELECT/  enclosed  in  parentheses.  If  this  statement  is  not 
present,  the  entire  file  will  be  punched. 

A  /FIELDS/  statement  indicates  which  fields  CS3IFY  should 
use.  The  fields  labels  are  enclosed  in  parentheses  and 
immediately  follow  the  "/FIELDS/"  statement. 

If  the  "ossified"  file  is  intended  for  editing  on  Wylbur, 
use  the  /WIDTH/  statement  so  that  the  line  length  will  allow  some 
"editinq  room"  on  each  line.  The  minimum  width  is  20.  The 
ossified  file  is  routed  to  F1Q7F001. 


Sample  control  stai 


/ID/INPOT  FILE  IDENTIFIED 
/SELECT/  { 7 ,  100,50-63) 
/WIDTH/  (50) 

/FIELDS/ ( A UTH,TITL,  YEAR) 
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This  program  rearranges  the  records  in  a  file  into 
alphabetical  order,  using  any  field  or  combination  of  fields  as 
the  sort  ke  y.  The  sort  key  is  the  portion  of  the  record  which  is 
used  tor  alphabetical  comparisons. 

It  is  not  possible  tc  define  a  part  of  a  field  as  the  sort 
key.  This  limitation  should  be  considered  when  designing  the 
structure  of  the  record.  For  example,  in  the  case  of  a 
monographic  file,  if  both  author  and  title  catalogues  are  to  be 
produced  by  neans  of  SOBT  and  GALLEY  jobs,  author  and  title 
information  should  not  be  incorporated  in  a  single  field. 
Conversely,  if  the  date  will  never  be  reguired  as  a  sort  key  it 
could  be  included,  if  desired,  in  one  of  the  other  fields.  See 
flULTIPLY  for  an  escape  froa  this  liaitation. 


Sort  key  comparisons 

The  order  of  two  records  is  decided  by  coaparing  their 
sort  keys  character  by  character  froa  left  to  right.  As  soon  as 
a  mismatch  between  a  pair  of  characters  is  found  the  records  are 
ordered  on  the  basis  of  an  internal  collating  sequence. 


Ihg_£gllatiiL3_sequeii£g 

It  should  be  explained  that  characters  are  represented 
within  computers  by  numeric  codes  which  differ  froa  machine  to 
machine.  The  IBM  363  uses  EECOIC,  a  code  in  which  characters  are 
represented  by  numbers  in  the  range  0  to  255.  Ey  arranging  the 
codes  in  ascending  order  a  machine  dependent  collating  seguence 
is  obtained,  which  could  be  used  for  sorting.  Faaulus,  however, 
converts  to  its  own  internal  collating  seguence  so  that  the  same 
sort  order  can  be  obtained  irrespective  of  the  machine  on  which 
the  pregram  is  run. 

Blank  precedes  other  characters.  Care  must  be  taken  in 
certain  cases  to  pad  the  data  with  blanks  or  noughts  to  ensure 
correct  allignnent  of  the  keys.  For  instance,  15  will  coae 
before  5,  but  after  05.  Famulus  removes  leading  blanks,  so 
another  character  must  be  used  for  padding  at  the  beginning  of  a 
field. 


SOET  requires  an  input  data  set  (DDNAME  FT01P001)  in 
Famulus  internal  form  cn  tape  cz  disc,  as  produced  by  the  EDIT 
proqrai.  It  creates  a  new  sorted  file  (FT02F301),  and  the  input 
file  remains  unchanged.  The  sorted  file  is  not  printed.  Only  a 
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listing  of  the  program  control  statements  and  technical 
information  such  as  the  number  of  records  processed  is  given, 
plus  an  indication  that  processing  was  successfully  completed. 
GALLEY  may  be  used  to  print  the  new  file. 


Program  control  statements 

The  /ID/  control  statement  contains  an  identifier  which 
must  match  that  of  the  input  file.  This  control  statement  is 
obligatory,  and  must  precede  the  rest,  which  are  optional. 

The  /FIELDS/  statement  defines  the  sort  key.  Any  or  all 
of  the  field  labels  in  the  input  file  may  be  given,  in  any  order. 
When  records  are  compared,  if  the  first  field  is  identical  the 
second  or  subsequent  fields  are  used  to  determine  precedence. 

Cn  the  output  file  of  sorted  records  the  fields  are 
ordered  as  specified  in  the  /FIELDS/  statement,  and  any  fields 
not  specified  remain  in  the  order  already  established  in  the 
input  file.  If  this  statement  is  absent,  the  implicit  order  of 
fields  in  the  input  file  is  assumed.  If  GALLEY  is  used  to  print 
tne  sorted  file  the  fields  will  be  printed  in  the  new  order 
estaolished  by  SOFT,  unless  another  /FIELDS/  statement  is  used 
for  GALLEY. 

The  /SELECT/  statement  may  be  used  to  break.  large  files 
into  sections  for  more  efficient  sorting.  It  is  recommended  to 
sort  up  to  3000  records  at  a  time  and  then  merge  the  sorted 
sections.  If  this  statement  is  absent  the  wbcle  file  is  sorted. 

A  /NEW  ID/  statement,  may  optionally  be  used  tc  specify  a 
new  identifier  for  the  output  tape. 


Sample  control  statements  for  SOBT 


/ID/DB ACONCULOS  B IBLIOGK APH Y 
/FIELDS/  (AUTH ,  YEAR) 

/SELECT/  (  1-  2500) 

/NEW  1 D/FIFST  HALF 
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This  program  provides  the  updating  facility  for  Famulus- 
controlled  files.  It  aerges  any  "master  file"  with  an  "additions 
file".  SERGE  can  be  used  for  twc  purposes  -  to  update  files  by 
merqinq  information  froa  two  files  onto  one  output  file,  or  to 
join  files  belonginq  to  two  or  aore  persons.  For  instance,  the 
various  aeabers  of  a  working  group  aay  maintain  separate 
literature  files,  but  on  occasion  they  aay  wish  to  aake  a  aaster 
listinq  of  all  these  files. 

MERGE  will  only  accept  input  files  having  the  sane  number 
of  fields;  however,  the  field  names  do  not  have  to  be  the  same. 
The  master  file  (with  the  DDNAME  PT0  1F00  1)  and  the  additions  file 
(FT03FC01)  will  be  merged  and  written  onto  the  output  file 
(PT02F00 1 ) .  The  field  labels  on  the  output  or  updated  file  will 
be  the  same  as  those  occurring  on  the  aaster  file.  The  /ID/  will 
also  be  taken  from  the  aaster  file,  unless  a  /NEW  ID/  stateaent 
is  included. 

Any  record  which  is  not  in  correct  alphabetical  order  will 
cause  the  MERGE  program  to  halt  processing,  reject  the  remainder 
or  the  job,  and  print  an  error  aessage.  Therefore,  only  files 
which  have  been  ordered  in  the  sane  way  by  the  SORT  program 
snould  be  input.  Unless  specifically  reguested,  MERGE  does  not 
print  out  the  file.  It  prints  the  /ID/  of  the  master  file,  the 
/ID/  of  *he  additions  file  ,  and  the  /ID/  of  the  output  file 
alonq  with  the  field  labels  for  each.  This  will  be  followed  by 
the  number  of  records  cn  the  newly  updated  file  and  the  familiar 
three  large  CK's. 


Prqqpam  control  statements 

An  /ID/  statement  for  the  aaster  tape  (FT01F001)  and  an 
/ID/  statement  for  the  additions  tape  (FTO.IPOOI),  in  that  order, 
are  mandatory. 

A  /NEW  ID/  should  be  included  if  a  different  /ID/  from  the 
master  file  is  desired  for  the  output. 

The  output  file  is  not  normally  printed  in  full.  If  no 
/PRINT/  statement  is  included  ten  records  will  be  printed. 
Otherwise  the  records  specified  will  be  printed.  A  /PRINT/ (0) 
statement  will  suppress  printing  of  records  altogether. 

A  line  width  of  128  characters  is  normally  used,  but  this 
may  te  altered  to  any  value  in  the  range  20  to  128  by  the  use  of 
a  /WIDTH/  statement. 
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Note  that  in  the  original  system  /PRINT/  in  MERGE  served 
the  sane  purpose  as  /WIDTH/  in  the  other  programs  such  as  EDIT, 
(see  the  Famulus  Users  Manual,  1969).  For  the  sake  of 
consistency,  compatible  /PRINT/  and  /HIDTH/  statements  as 
described  above  are  now  implemented  in  MERGE. 


Sample  control  statements  for  MERGE 


/ID/FIRST  HALF 
/ID/SECOND  HALF 

/NEW  ID/DR ACU  NCULUS  BIELICGR APHY  - 
/P  H  IN  T  /  (  11-2  1) 

/WIDTH/  (65) 


AUTHOR  CATALOGUE 
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This  program  is  designed  to  handle  problems  arising  froa 
multiple  entries  in  a  field  -  multiple  authorship  is  a  typical 
example.  When  two  cr  sore  autnors*  names  appear  in  the  author 
field  a  listing  of  the  file  sorted  by  author  will  not  be  a 
complete  author  catalogue  unless  the  file  is  first  multiplied  to 
produce  a  complete  new  record  for  each  entry  in  the  author  field. 
This  is  the  function  of  MULTIPLY. 

The  input  file  identifier  must  agree  with  the  naae  on  the 
obligatory  /ID/  control  statement.  The  output  file  identifier 
will  be  the  same  unless  specified  otherwise  on  a  /NEW  ID/  control 
statement. 


The  mu  It  iplication  field 

The  input  file  may  be  multiplied  on  one  field  only,  but 
any  field  may  be  used.  A  record  is  generated  in  the  output  file 
for  each  entry  in  the  a ulti plica tion  field,  which  is  specified 
either  by  a  /FIELDS/  statement  containing  only  one  field  label  or 
by  a  /DESCRIPTOR  FIELD/  statement,  depending  upon  whether  entries 
are  to  consist  of  separate  words  or  of  character  strings  bounded 
by  a  delimiting  character.  Any  character  may  be  defined  as  the 
delimiter,  the  default  being  comma.  A  /DESCRIPTOR  FIELD/ 
statement  will  override  any  previously  defined  descriptor  field. 
If  neither  a  /FIELDS/  ncr  a  /DESCRIPTOR  FIEID/  statement  is 
supplied  the  previously  defined  descriptor  field  becomes  the 
multiplication  field,  and  if  none  exists  the  program  terminates 
with  an  error  messaqe.  All  the  fields  in  the  output  record 
remain  the  same  as  in  the  input  record  except  the  multiplication 
field,  which  contains  only  one  of  the  words  or  phrases  in  the 
oriqinal.  If  the  multiplication  field  in  any  record  is  empty  no 
output  record  is  created;  this  is  eguivaleDt  to  multiplication  by 
zero. 


Apart  from  the  usual  control  statement  listing  etc.,  the 
printed  output  from  MULTIPLY  is  limited  to  the  first  ten  records 
of  the  output  file.  This  should  normally  be  sufficient  to  check 
the  operation  of  the  program.  To  obtain  more  (or  less)  output 
tne  required  number  of  records  should  be  specified  oy  means  of  a 
/PRINT/  control  statement. 

Records  are  printed  in  the  fields  format,  with  the  record 
number  on  the  left  and  cn  the  right  the  number  of  the  input 
record  from  which  it  was  derived.  The  number  of  characters 


Faaul  us 


A  Documentation  System  {MULTIPLY) 


23 


printed  per  line  can  oe  reduced  from  the  normal  128  by  means  of 
the  /iilDTH/  statement.  The  minimum  is  20. 


S* ffiPie  control  statements  for  HUITIPLT 


/ID/DE  AC  UNCUL  US  BIBLIOGiiAPH  Y 
/DESCRIPTOR  FIELD/  (AUTH)  {,) 
/PRINT/  (75) 

/ »I DTH/  (80) 


AD-A0B4  840  MISSION  RESEARCH  CORP  SANTA  BARBARA  CA  F/8  9/2 

DEVELOPMENT  OF  A  PHYSICAL  SECURITY  DATA  MANASEMENT  SYSTEM.  VOLU— ETC(U) 

nov  79  j  Caldwell r  p  benner.  d  solomonson  dnaooi-79-c-ou2 
UNCLASSIFIED  MRC-R-53I  CEL  -CR-80.013  NL 


Famulus  -  A  Documentation  System  (GALLEY) 


24 
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GALLEY  will  print  a  Paaulus  file  with  a  choice  of  four 
f  oraa  ts. 


Pile  identification 

The  file  to  be  printed  aust  be  identified  by  an  /ID/ 
control  statenent  with  the  correct  file  identifier.  This  is  the 
only  obligatory  control  statement,  and  it  aust  precede  any 
others. 


^£liIllM._£0.£txgnsi_,2l..a_file 

Selected  portions  of  a  file  may  be  printed  by  specifying 
the  required  records  on  a  /SELECT/  statenent.  This  contains  a 
list  of  record  numbers  separated  by  coamas.  Ranges  cf  records 
are  denoted  by  a  dash  instead  of  a  comma  between  two  nuabers. 
The  whole  list  is  enclosed  in  parentheses. 

Mote  that  the  record  nuabers  need  not  be  in  order,  but  the 
records  will  be  printed  in  file  order,  not  the  order  on  the 
/SELECT/  statement. 


Printed  output  formats 

The  standard  default  format  prints  the  fields  in  seguence 
without  starting  a  new  line  for  each  field,  and  also  drops  the 
field  labels,  simply  leaving  three  spaces  between  fields. 

1.  THIS  IS  THE  FIRST  FIELD.  THIS  IS  THE  SECOND. 

The  /PRINT  BY  FIELDS/  statement  produces  an  output  with 
field  labels,  each  field  beginning  on  a  new  line,  like  the  output 
from  EEIT. 

1  FLD 1  THIS  IS  THE  FIRST  FIELD. 

FLD2  THIS  IS  THE  SECOND. 

The  /PRINT  BY  SUBJECTS/  statenent  will  print  a  file 
without  field  labels  but  with  subject  headings.  The  first  field 
named  in  the  /FIELDS/  statement  is  printed  as  a  heading  above  the 
remainder  of  the  record.  The  first  field  of  subseguent  records 
is  only  printed  if  it.  differs  from  the  previous  record.  The 
length  of  the  first  field  should  not  exceed  the  printed-page 
width,  otherwise  it  will  be  truncated. 

THIS  IS  THE  FIRST  FIELD. 


THIS  IS  THE  SECOND 
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The  /TABS/  statement  prints  the  fields  in  tanular  fashion 
accordinq  to  the  tabs  set  in  the  text  of  the  /TABS/  stateaent. 
The  columns  are  indicated  by  a  list  of  nuabers  separated  by 
commas  and  enclosed  in  parentheses.  For  the  stateaent 
/TABS/ (5  ,20)  : 

THIS  IS  THE  F  THIS  IS  THE  SECOND. 

IE  ST  FIELD. 

This  option  is  obviously  suited  to  long  lists  of  snail 
fields  (e.g.  part  numbers) 

/PRINT  BY  FIELDS/ ,  /PBINT  EY  SUBJECTS/  and  /TABS/  are 
mutually  exclusive  options.  If  neither  stateaent  is  present  the 
standard  print  format  is  produced  by  default. 


Omit  ting  fields 

The  /FIELDS/  statement  in  GALLEY  is  used  to  define  which 
fields  of  the  record  are  to  be  printed,  giving  the  user  the 
option  of  omitting  fields.  The  fields  will  be  printed  in  the 
order  in  which  they  appear  on  the  /FIELDS/  statement,  regardless 
of  their  order  in  the  input  file.  If  no  /FIELDS/  stateaent  is 
supplied  all  the  fields  of  the  record  are  printed  in  the  order 
implicit  in  the  file. 

Page  heading 

The  /NEW  ID/  statement  is  available  in  GALIEY,  but  since 
no  output  file  is  produced  by  this  program  it  is  cnly  used  to 
supply  a  heading  which  will  be  printed  at  the  top  of  each  page  of 
output.  If  this  statement  is  omitted  the  input  file  identifier 
is  printed  as  a  pace  heading. 


Page  width,  depth  ana  spacing 


The  reguired  page  width  may  be  obtained  by  means  of  a 
/WIDTH/  statement.  It  may  range  from  20  characters  up  to  the 
normal  128.  As  a  guide,  ten  characters  occupy  an  inch  on  many 
lineprinters. 


The  number  of  lines  per  page  can  be  set  using  the  /DEPTH/ 
statement  in  a  similar  manner  to  the  /WIDTH/  statement.  The 
minimum  is  13  and  there  is  nc  maximum. 


Spaces  can  be  inserted  between  lines  of  print  using  the 
/SPACE/  statement  in  a  similar  manner  to  the  /WIDTH/  statement. 
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Omitting  Record  Numbers 

The  /PRINT  NC  K UMBER 5/  statement  suppresses  the 
numbers  from  the  printed  output. 


Sam tie. control. statg»ents_f cc_GALLSl 


/ID/FIELD  REPORTS 
/FIELDS/  (NAME,  NUMB  ,OCC  ,AD  ,DATA) 
/SELECT/  (1-5,15-20,25,30,  11,8,23,21) 
/WIDTH/  (100) 

/PRINT  BY  FIELDS/ 

/NEW  ID/  SELECTED  FEPCBTS. 

/DEPTH/  (30) 

/SPACE/  (2) 

/PRINT  NO  NUMBERS/ 


record 
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The  index  which  this  program  provides  is  an  alphabetical 
list  of  terms  in  the  descriptor  field  of  a  file.  Each  term  is 
accompanied  by  a  list  of  references  to  the  records  where  it 
occurs,  separated  by  commas.  A’  record  is  referenced  by  its 
position  in  the  input  file,  which  is  printed  as  an  integer  to  the 
left  of  the  record  in  the  GALLE7  listing  of  the  file.  The  index 
is  normally  used,  therefore,  in  conjunction  with  a  complete 
listing  for  indirect  access  to  records  via  an  attribute  other 
tnan  the  one  by  which  the  file  is  ordered,  such  as  subject 
categories. 


Tne  descriptor  field 

The  INDEX  program  is  only  designed  to  operate  on  the 
descriptor  field  of  a  file  to  produce  a  thesaurus  cf  descriptor 
terms.  The  descriptor  field  may  have  been  previously  defined, 
most  likely  by  EDIT  when  the  file  was  created,  hut  if  not  a 
/DESCF.  IPTOh  FIELD/  control  statement  is  required.  This  statement 
is  also  neccessary  if  the  default  delimiter,  comma,  is  to  be 
overridden  by  another  character. 

An  index  or  any  other  field  can  be  produced  by  using  a 
/DESCFIPTOF.  FIELD/  statement  to  define  it  temporarily  as  the 
descriptor  field  with  an  appropriate  delimiter.  This  overrides 
the  previously  nominated  uescriptor  field,  if  any,  as  far  as  the 
present  run  of  the  INDEX  program  is  concerned,  but  the  original 
information  m  the  input  file  remains  intact  for  future  use. 


Printed  index 

The  /NEW  ID/  control  statement  is  available  to  specify  a 
heading  for  the  printed  output.  Descriptor  terms  longer  than  40 
characters  are  truncated  during  printing  of  the  index.  Terms  are 
printed  in  alphabetical  order,  each  with  its  list  cf  references 
on  tne  following  line  or  lines. 


Punched  card  index 


An  optional  /PUNCH/  control  statement  causes  the  index  to 
be  punched  out  on  cards  to  produce  a  manual  card  index.  This 
facility  is  particularly  useful  where  a  complete  index  of  the 
whole  file  cannot  be  made  because  the  file  contains  toe  many 
index  terms. 


Famulus  -  A  Documentation  System  (INDEX) 


28 


In  this  case  the  file  can  be  indexed  in  sections  by 
including  /SELECT/  control  statements  in  separate  runs  to  select 
successive  sets  of  records.  The  punched  card  output  froa  the 
different  runs  can  then  be  merged,  disstateaenting  duplicate 
descriptor  headings,  tc  produce  a  master  index  to  the  whole  file. 

The  capacity  of  the  prograa  is  liaited  to  2000  different 
descriptor  terms  referenced  up  to  2500  tiaes. 


Page  width  and  depth 

As  in  GALLEY  the  nuaber  of  characters  in  a  line  and  the 
number  of  lines  per  page  can  be  adjusted  with  the  /WIDTH/  and 
/DEPTH/  statements. 


Sample  control  statements  for  INDEX 


/ID/M ASTER  FILE 

/HEW  IE/  IKDEX  OF  BECOBDS  1001  -  2000 
/SELECT/  (100  1-2000) 

/DESCE IPTOE  FIELD/ (KEY)  (;) 

/PUNCH/ 

/WIDTH/ (70) 

/DEPTH/  (40) 
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SEARCH 


This  proqram  selects  records  £roi  a  Famulus  file  in 
response  to  requests  for  information. 

The  file  to  be  searched  Bust  be  correctly  identified  by  an 
/ID/  control  statement. 


Searching  subsections 

The  /SELECT/  statement  aay  be  used  to  indicate  the  record 
numbers  which  are  tc  be  searched.  It  is  sometimes  possible  to 
use  this  facility  to  narrow  the  area  of  search  tc  coe  or  more 
subsections  of  the  complete  file.  Per  instance,  if  a  file  is  in 
chroncloqical  order  the  record  numbers  delimiting  any  particular 
period  of  interest  will  be  known  fro®  the  GALLEY  listing. 
Selecting  a  subsection  of  a  file  in  this  way  obviously  cuts  down 
processing  time,  but  it  has  greater  potential  in  conjunction  with 
the  /SEARCH/  formula  to  help  define  the  set  cf  records  to  be 
retrieved.  In  many  cases,  however,  the  attribute  by  which  the 
file  is  orderea  is  not  among  the  retrieval  criteria,  arid  there  is 
then  no  alternative  but  tc  search  the  whole  file.  In  this  case 
no  /SELECT/  statement  is  required. 


De  f  1  n  i  n  g  the  f ields  to  be  searche d 

One  or  more  fields  cf  each  record  are  scanned  to  determine 
waether  it  meets  the  criteria  for  retrieval,  and  a  /FIELDS/ 
control  statement  is  used  to  list  the  relevant  field  labels.  The 
fewer  the  fields  that  have  to  be  scanned  the  more  efficient  the 
search  will  be.  If  this  statement  is  absent  the  descriptor  field 
is  used,  and  if  no  descriptor  field  was  defined  the  program 
terminates  with  ar  error  message.  If  no  descriptor  field  was 
defined  when  the  file  was  first  created  a  /DESCRIPTOR  FIELD/ 
control  statement  may  be  used  to  define  one  for  the  purpose  of 
the  SEARCH  program,  or  if  the  descriptor  field  already  exists,  to 
cnanqe  it.  Eear  in  mind  that  the  method  of  identifying  terms 
depends  upon  whether  the  field  is  a  descriptor  field  or  not. 


£EiHl£i_21LLELyt 


The  printed  output  produced  by  SEARCH  is  normally  a 
listinq  in  full  of  all  the  records  that  satisfy  the  /SEARCH/ 
requests.  Two  formats  are  available,  the  default  listing  and  a 
tabular  output.  The  /TABS/  statement  produces  the  tabular  list 
in  exactly  the  same  way  GALLEY  does.  Ihe  default  listing  is 
identical  to  the  default  in  GALLEY. 


TS *~v 
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The  aaouat  of  printing  can  be  reduced  if  desired  by  a 
/NUMBERS/  control  stateaent  which  results  in  rcccrd  nuabers  only 
being  listed.  The  /WIDTH/  and  /DEP1H/  stateaents  are  available 
for  changing  the  line  width  of  the  output  and  the  nuaber  of  lines 
per  page,  respectively.  Spaces  can  be  inserted  between  lines  of 
the  output  with  the  /SPACE/  statement.  The  /HEW  ID/  stateaent 
enables  the  page  beading  to  be  specified  if  it  is  to  be  different 
from  the  input  file  /ID/.  The  /PRINT  NO  NUMBERS/  statement 
suppresses  the  citation  numbers  froa  output. 


Sieat  iB2L4.  new.. file 


If  required,  a  new  file  containing  the  retrieved  records 
can  be  created  by  using  a  /WRITE  TAPE/  (appropriate  JCL  will 
route  output  to  any  desired  location)  control  stateaent,  and  its 
/ID/  will  be  the  saae  as  the  page  heading  of  the  printed  output. 


The  search  formula 

Retrieval  of  records  froa  the  input  file  is  achieved  by 
means  of  a  formula  on  the  /SEARCH/  control  statement.  The  search 
formula  is  composed  of  terms  combined  with  Boolean  operators, 
written  in  free  format. 

Terms  are  defined  according  to  the  usual  convention, 
broadly  speakinq,  as  phrases  bounded  by  a  delimiter  in  a 
descriptor  field  and  words  elsewhere.  In  this  program,  however, 
there  are  also  two  additional  features,  truncation  and 
qualification,  which  are  described  later. 

The  three  logical  operators  permitted  in  a  search  foraula 
are  aa<i,  &E.  and  not,  represented  in  EBCDIC,  the  IBM  360  character 
code,  by  the  characters  5,  j  and  respectively. 

Use  of  the  and  operator  implies  that  the  user  only  wants 
to  retrieve  records  in  which  all  the  terns  joined  by  and  are 
present.  If  a  single  one  of  the  specified  terns  is  aissing,  the 
record  will  net  be  retrieved.  The  &£  operator  will  retrieve 
records  in  which  any  of  the  specified  terns  are  present.  The  not 
operator  indicates  that  records  containing  the  tern  which  follows 
it  will  not  be  retrieved. 

Parentheses  should  be  used  to  avoid  ambiguity  as  to  the 
order  in  vbich  the  operations  should  be  performed.  There  is  no 
Halt  to  the  depth  to  which  parentheses  say  be  nested.  Limits  on 
the  size  of  the  search  foraula  reguire  that  not  note  than  fifty 
different  terns  (or  sixty,  including  duplicates)  for  a  total  of 
150  terms  and  operators  be  used  in  one  foraula. 


ft 
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Vocabulary  lists 

Tbe  descriptor  field  usually  contains  a  controlled 
vocabulary  and  there  is  then  no  difficulty  in  chocsing  the 
correct  terms,  but  for  seaching  any  field  with  an  uncontrolled 
vocabulary  it  is  useful  to  refer  to  a  list  of  the  vocabulary  in 
that  field  produced  by  COUNT  or  VCCAB. 


Truncation  of  terms 

For  instance,  a  title  field  will  contain  an  uncontrolled 
vocabulary,  because  you  had  no  say  in  the  choice  of  words  used  by 
the  original  authors  in  their  titles.  Several  forms  of  the  same 
word  may  occur  —  for  example,  regenerate,  regenerating, 
regeneration.  In  order  to  retrieve  records  containing  any  of 
these  forms  it  is  permissible  to  truncate  on  the  right  and 
specify  a  common  substring  —  e.g.,  re gene rat  or  even  regen  -- 
thouqh  by  usinq  too  short  a  form  you  run  the  risk,  of  retrieving 
irrelevant  words  such  as  regent .  Truncation  on  the  left  is  not 
permissible. 


Qualification  of  terms 

The  terms  are  normally  searched  for  in  the  fields 
specified  by  the  /FIELDS/  statement.  Sometimes  there  is  a  need 
to  include  a  term  from  another  field,  such  as  an  author  or  date. 
This  is  done  simply  by  following  tne  term  with  the  field  label 
enclosed  in  parentheses. 

SMITH  (AUTH)  or  1948  (DATE) 


tipper  and  lower  case  text 

To  search  for  upper  and  lower  case  text,  prepare  the  data 
on  Wylbur  or  use  the  Famulus  flag  characters  described  in 
Appendix  C.  For  card  usage,  a  /FLAGS/  card  should  precede  a 
/SEARCH/  card. 
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MAhSLS 


If  you  specify  /N0MB£RS/(0)  before  a  /SEABCB/  coaaand, 
Faaulus  will  only  report  how  aany  citations  meet  the  search 
criteria.  The  coaaand  /NUMBERS/  without  any  argument  will  return 
a  list  of  the  citation  nuabers  that  aet  the  search,  as  well  as 
tell  you  how  saDy  iteas  were  found. 


Multiple  searches  of  the  file  aay  be  carried  out  by 
supplying  wore  than  one  /SEABCH/  stateaent.  The  input  file  is 
rescanned  for  each  search,  and  while  there  is  no  liait  to  the 
number  of  searches,  the  co-st  is  obviously  proportional. 

At  least  one  /SEABCH/  stateaent  is  obligatory.  Mot  only 
is  it  the  aeans  by  which  criteria  for  record  retrieval  are 
expressed,  it  is  also  the  signal  for  processing  of  the  input  file 
to  begin,  and  therefore  oust  follow  all  the  other  control 
statements. 


Sam  cl  e  control  statements  for  SEARCH 


/ID/M ASTER  FI IS 
/FIEL  CS/  (TITL  ,KEY) 

/SEARCH/  SOIL  STABILITY  6  (EBOSION  J  SLIDES)  &  196  [DATE) 
/SEARCH/ [PANCHROMATIC  |  I NFBABED  |  THERMAL  |  BADAE) 

8  AERIAL  B  7CMM 
/NEW  ID/THIRD  SEABCH 
/WIDTH/ (70) 

/DEPTH/  (132) 

/SPACE/ (2) 

/NUMBEES/  (1-70) 

/PBINT  NO  KOMBEBS/ 

/SELECT/  (7 ,100,25-30) 

/WRITE  TAPE/ 
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COUNT  and  VCCAB 


The  COUNT  program  lists  the  vocabulary  in  specified  fields 
of  a  Famulus  file  in  alphabetical  order  with  a  count  of  the 
number  of  times  each  item  occurs.  Statistics  concerning  word 
occurances  and  word  lengths  are  also  printed. 

The  VOCAB  program  performs  the  same  function  except  that 
word  frequencies  are  not  counted. 

Thouqh  requiring  less  space  than  COUNT,  VOCAB  is 
relatively  undeveloped,  and  parts  of  the  following  discussion  do 
not  apply  to  it,  notably  the  /STOP  LEVEL/  feature.  A  punched 
statement  vocabulary  list  is  produced  automatically,  and  the 
/PUNCh/  control  statement  is  not  available.  The  /NEW  ID/  and 
/DESC B1PT0F.  FIELD/  control  statements  are  also  unavailable.  It 
is  assumed  ttat  COUNT  will  normally  be  preferred. 


Uses  of  vocabulary  lists 

Vocabulary  lists  have  a  number  of  uses:  data  validation, 
search  formula  construction,  thesaurus  building,  and  simple 
research  on  the  information  contained  in  the  file. 


Error  detection 


In  the  early  stages  of  data  base  construction  a  vocabulary 
list  will  throw  errors  such  as  miss-spellings  intc  prominence,  so 
providinq  a  check- list  of  errors  for  use  in  data  correction. 
Proof-reading  is  not  eliminated,  because  the  errors  still  have  to 
be  located,  but  they  can  at  least  be  traced  to  one  of  the  fields, 
which  narrows  the  area  cf  search. 


Breakdown,  of  .vocabulary  by.  fields 

The  fields  whose  vocabulary  is  reguired  are  specified  on  a 
/FIELDS/  control  statement,  the  descriptor  field  being  the 
default.  A  /DESCRIPTOR  FIELD/  statement  will  override  any 
existinq  descriptor  field.  This  feature  allows  vocabulary  items 
consisting  of  phrases  separated  by  any  specified  delimiter. 

Vocabulary  lists  are  often  reguired  to  help  construct 
search  formulas,  and  then  it  is  useful  to  know  the  fields  in 
which  particular  items  occur.  A  breakdown  of  the  vocabulary  by 
fields  is  not  provided,  however,  and  the  only  way  to  achieve 
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this  result  is  to  run  the  prograa  repeatedly  with  a  /FIELDS/ 
stateacnt  specifying  a  different  field  each  tiae.  Otherwise  if 
aore  than  one  field  is  specified ,  a  coabined  list  is  produced 
which  will  not  show  which  field  a  word  cane  froa. 


Stop-list  compilation 

Vocabulary  lists  are  also  useful  for  constructing  a 
controlled  thesaurus  of  index  teras  for  use  in  the  descriptor 
field.  If  the  /PUNCH/  control  stateaent  is  supplied,  a  punched 
card  deck  of  the  vocabulary  is  autoaat ically  produced,  consisting 
of  a  list  of  words  in  alphabetical  order,  separated  by  coaaas. 
These  cards  aay  be  modified  and  used  in  a  later  run  following  a 
/VOCABULARY/  stateaent  in  order  to  specify  a  stop-list  of  trivial 
words.  Trivial  and  non- trivial  vocabularies  are  then  printed  in 
separate  lists.  The  aodification  to  the  card  deck  siaply 
involves  replacing  the  comma  following  every  trivial  word  with  an 
asterisk.  This  deck  can  also  be  used  by  the  KEY  prograa. 

There  is  also  provision  for  autoaat ically  transferring 
words  from  the  vocabulary  to  the  trivial  list  if  they  occur  too 
frequently. 

/STOP  LEVEL/  (25) 


This  stateaent  will  put  any  word  occurring  25  tiaes  or 
aore  into  the  trivial  word  list  in  the  printed  output,  and  will 
mark  it  as  trivial  by  an  asterisk  in  the  punched  card  output,  if 
any. 


Vocabulary  lists 

If  any  words  are  marked  as  trivial  a  list  of  trivial  words 
in  alphabetical  order  is  printed  first.  The  ncn-trivial 

vocabulary  list  is  printed  next,  followed  by  the  coaplete 
dictionary  in  order  of  word  freguency  with  trivial  words 
distincu ished  by  a  following  asterisk.  Tne  word  lists  are 
printed  in  three  columns  across  the  width  of  the  page.  Each 
word,  cr  phrase  in  the  case  of  a  descriptor  field  vocabulary 
list,  is  followed  by  its  actual  and  percentage  freguency  of 
occurrence.  If  the  actual  freguency  exceeds  four  decimal  digits 
asterisks  are  printed  in  lieu. 

Any  item  which  is  too  long  to  be  acconnodated  in  the 
column  is  truncated  to  33  characters.  This  is  not  likely  to 
occur  except  when  counting  a  descriptor  field,  because  the 
longest  word  in  the  Oxford  English  Dictionary  consists  of  28 
letters. 
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The  VCCAE  program  provides  no  word  frequency  count  and 
tnerefore  allows  up  to  41  characters  before  truncating.  The 
extra  seven  characters  nay  sometimes  be  just  enough  to  resolve 
ambiguity,  which  is  the  main  occasion  for  using  VOCAB  in 
preference  to  COUNT. 


Statistics  of  word  types 

Dictionary  statistics  are  provided  separately  for  the 
words  in  the  stop-list  and  for  the  remainder  of  the  vocabulary. 
Both  sets  of  statistics  consist  of  a  table  of  word-length 
distr  ibutions  followed  by  the  number  of  entries,  their  average 
and  maximum  lengths,  and  details  of  the  dictionary  size.  The 
word-length  distribution  table  comprises  four  rows  and  ten 
columns.  Each  value  in  the  table  represents  the  nuaber  of 
dictionary  entries  having  a  certain  nuaber  of  characters.  The 
first  row  gives  the  values  for  terms  having  one  to  ten 
characters;  the  second,  for  11  to  20  characters;  the  third,  for 
2 1  to  30  characters;  and  the  fourth,  for  31  to  40  characters. 


Statistics  of  word  tokens 

The  distinction  between  types  and  tokens  is  fundaoental. 
Word  types  hardly  require  explanation;  they  are  siaply  the 
different  words  found  m  the  input  file  and  entered  into  the 
program's  internal  dictionary.  When  different  instances  of  a 
sinqifc  word  type  are  encountered  i  the  file  they  constitute 
separate  word  tokens. 

Statistics  of  word  tokens  are  -provided,  as  for  word  types, 
both  for  trivial  and  for  vocabulary  words.  In  each  case  the 
distribution  of  werd  frequencies  is  tabulated  under  six  headings 
across  the  page  as  follows; 

R  the  rank  cf  N,  increasing  by  cne  cn 

successive  lines. 

N  the  nuaber  of  tokens  of  any  one  word  type,  in 

decreasing  order. 

F  (N )  the  number  of  word  types  having  N  tokens. 

This  tends  to  increase  as  K  decreases. 

SIGN A  (F  (N) )  the  cumulative  sum  of  word  types  having  N  or 

more  tokens. 

N*F  (N)  the  number  of  word  tokens  of  rank  R. 

SIGMA  (N*F  (N)  )  the  cumulative  sum  of  word  tokens  of  the 

SIGMA  (F  (N) )  most  frequent  word  types  up 
to  and  including  rank  R. 
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Dictionary  capacity 

The  dictionary  limits  on  vocabulary  size  are  either  4500 
entries  or  45000  characters.  If  either  limit  is  exceeded  the 
program  will  not  proceed  with  the  reading  of  the  input  file,  but 
will  output  the  results  obtained  up  to  that  point. 

This  situation  can  easily  arise  with  large  files, 
especially  if  several  fields  are  being  scanned  in  a  single  job. 
Tnis  is  another  reason  for  scanning  one  field  per  run,  though 
even  this  may  not  solve  the  problem  for  very  large  files.  In 
such  a  case  the  vocabulary  of  the  unprocessed  portion  of  the  file 
nay  be  obtained  by  a  subseguent  run  using  the  /SELECT/  statement. 
The  starting  point  for  the  second  run  is  obtained  from  the  figure 
for  the  last  citation  inspected  in  the  output  from  the  first  run. 


The  last  citation  inspected 

Following  the  file  identification  information  in  the 
printed  output  the  number  of  the  last  citation  which  was 
inspected  is  given.  This  will  be  the  last  record  in  the  file,  or 
the  last  record  specified  in  a  /SELECT/  statement,  or  the  last 
record  read  before  the  capacity  of  the  program  was  exceeded. 


Samrle  control  statements  for  COUNT 


/ID/HAST  EH 

/NEK  ID/ABSTE ACT  V  CCABUL ABY  LIST 
/FIEL  DS/  (AB  ST) 

/PUNCH/ 

/VOCAtULAH¥/A*THE*AN*CEISIS,CF*IN* 
/STOP  LEVEL/ (20) 
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JL£X 


The  KEY  program  provides  au  automatic  keywording  facility 
for  Famulus  files,  using  existing  fields  as  the  source  for  key 
terms  or  descriptors.  The  program  hill  scan  one  or  more  fields 
in  a  record  ana  generate  entries  in  a  specified  key  field. 


Xhfi-LfJL-field 

Tne  field  which  is  to  receive  the  key  terms  is  specified 
cn  the  /KEY  FIELD/  statement  by  its  label  enclosed  in 
parentheses.  Only  one  field  label  is  permitted,  and  it  must  be 
one  of  the  field  labels  already  defined  by  EDIT  when  the  input 
file  was  created,  though  the  field  need  not  necessarily  contain 
any  information  yet.  When  creating  a  new  file  it  is  wise  to 
pre-define  mere  fields  than  are  immediately  required,  just  in 
case  an  unforseen  need  like  this  arises. 

If  the  key  field  of  any  record  is  not  empty,  entries  are 
simply  added  to  the  material  already  there.  Ho  entry  is 
duplicated  in  the  key  field,  even  if  it  occurs  more  than  once  in 
the  source  fields. 

Terms  are  separated  in  the  key  field  by  a  single  blank 
unless  a  separator  is  giveu  on  the  /KEY  FIELD/  statement.  Any 
sinqle  character  may  be  specified,  enclosed  by  parentheses, 
following  the  field  label.  When  a  separator  is  supplied  it  is 
inserted  followed  by  an  extra  blank  between  terms  in  the  key 
field. 

The  /KEY  FIELD/  statement  is  obligatory. 


The  source  fields 

Terms  are  identified  as  in  SCLTIPLY,  i.e.,  strings  bounded 
ny  a  delimiter  when  scanniug  the  descriptor  field,  and  single 
words  when  scanning  the  ether  fields.  Unlike  BULTIPLY,  however, 
KEY  can  operate  on  more  than  one  field. 

The  fields  to  be  used  as  the  source  for  single  word  terms 
are  specified  on  a  /FIELDS/  statement,  the  descriptor  field 
servinq  as  the  default.  The  /DESCRIPTOR  FIELD/  statement  is  also 
available  to  define  a  source  field  and  delimiter  for  terms 
consisting  of  bounded  strings.  This  field  becoies  the  implicit 
descriptor  field  of  the  output  file,  irrespective  of  the  inphit 
file  descriptor  field. 
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Sigj?  ,aflfl-ag-lisis 

KET  has  an  internal  dictionary  to  store  terms  which  ere 
input  via  control  statements.  During  processing  of  each  record 
every  term  in  the  source  fields  is  checked  to  find  out  whether  it 
is  in  the  dictionary  cr  net.  I t  is  then  only  transferred  to  the 
key  field  depending  upon  whether  the  dictionary  is  considered  to 
be  a  stop  list  of  unwanted  terms  or  a  go  list  which  excludes  all 
ether  terms. 

For  example,  the  dictionary  nay  represent  a  controlled 
thesaurus,  i.e.,  a  qc  list  cf  terms  which  are  required.  In  this 
case,  a  /GO  LIST/  control  statement  is  used  to  introduce  the 
thesaurus,  which  is  punched  on  statements  in  exactly  the  same 
fora  as  for  the  /VOCABULABY/  statement  of  COUNT,  with  terms 
separated  by  comas,  lihen  operating  with  a  go  list  the  program 
rejects  any  words  it  finds  which  are  not  in  the  list. 

Alternatively,  KEY  may  be  made  to  work  with  a  stop  list  by 
means  of  a  /STOP  LIST/  control  statement  containing  unwanted 
terms  each  followed  by  an  asterisk.  Hhen  the  program  operates  in 
this  mode  these  terms  are  rejected,  but  all  terms  not  found  in 
the  dictionary  are  placed  in  the  key  field. 

/GO  LIST/  and  /STCP  LIST/  statements  are  mutually 
exclusive.  If  neither  statement  is  used  the  program  operates  as 
if  it  were  in  stop  list  mode  with  an  empty  dictionary,  with  the 
result  that  all  terms  are  transferred. 

The  syntax  cf  stop  and  go  lists  has  deliberately  been  made 
compatible  with  the  punched  card  vocabulary  provided  by  COUNT,  so 
that  these  cards  can  be  used  for  KEY  with  minimal  changes  to 
commas  or  asterisks.  Starred  words  may  be  left  in  a  go  list,  and 
they  are  ignored  in  order  not  to  waste  space  in  the  dictionary. 
Similarly,  words  followed  by  a  comma  in  a  stop  list  are  not  added 
to  the  dictionary. 


SJY&on  yas 

There  is  also  a  feature  which  limits  the  number  of  terms 
required  on  the  thesaurus  for  the  file.  It  is  possible  to  define 
sets  of  two  or  more  terms  to  be  synonyms,  one  of  which  is 
considered  the  preferred  synonym.  Hhen  one  synonym  is  found  the 
preferred  synonym  cf  the  set  is  entered  in  the  key  field. 

The  /SYNONYMS/  statement  is  used  to  specify  synonyns.  Each 
preferred  term  is  followed  by  an  equals  sign  and  a  list  of 
synonyms  separated  by  commas.  There  is  a  comma  before  the  next 
preferred  term. 
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Printed  output 


Apart  from  a  listiny  of  c 
iuentif ication  information  the  print 
to  the  first  ten  records,  unless  a 
used  to  vary  it.  Page  width  can  te 
statement. 


ontrol  statements  and  file 
ed  output  fro*  KEY  is  limited 
/PRINT/  control  statement  is 
adjusted  using  the  /WIDTH/ 


Sample  control  statements  for  KEY 


/ID/Db.  ACONCtlLOS  BIBLIOGRAPHY 

/NEW  ID/  KEYED  DRACUNCULUS  EIELICGE APHY 

/fIELCS/(TITL,ABST) 

/KEY  FIELD/  (KEY)  (,) 

/STOP  LIST/  A*AN*THE*CF*FCiR*CR*IN*CN*TO*BY*PBOM* 
INTO*SINCE*THEN*WCRN,  CIS  EASE,  P  AR  AS  IT  E*T  HER  EFORE 
/SYNOK  YM  S/HELM INTH  =HELMI NTHIC ,H  EL  MI NTHCLCGIC  Al , 
HELKI  NlriCLOGIST  , H E 1  MI NTHCLOGY , 

INFECT  1C  N  =  INFECTED  ,  INFECTIONS 
/PRINT/  (50) 

/SELECT/  (1-30,  34,36,47-91,94-100) 

/WIDTH/  (65) 
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The  KHIC  program  (Key  Word  In  Context)  generates  a 
concordance  for  a  Faaulus  file.  An  alphabetical  list  of  words  is 
produced,  with  each  weed  ceutred  in  a  line  containing  as  each  as 
possible  of  the  context  to  its  iaaediate  left  and  right.  Bach 
line  also  contains  a  nuaber  referencing  the  record  froa  which  it 
coses. 


Restricting  operation 

Sections  of  the  file  can  be  processed  by  using  the 
/SELECT/  statement  to  pick  only  the  records  to  be  indexed. 


Specif  ying.  fields 

As  in  the  case  of  the  KET  program,  any  field  or 
combination  of  fields  say  be  specified  by  means  of  a  /FIELDS/ 
statement,  and  if  no  /FIELDS/  statement  is  supplied  the  implicit 
descriptor  field  serves  as  the  default.  A  /DESCRIPTOR  FIELD/ 
stateaent  defines  a  field  containing  multi-word  terms,  and  also 
the  delimiting  character  which  separates  them. 


■£l&g_£Hd_32_lists 

A  /STOP  LIST/  or  a  /GO  LIST/  stateaent  may  be  used  to 
restrict  the  nuaber  of  terms  to  be  concorded.  Since  a  line  of 
output  is  generated  for  every  term  token  (see  COUNT  and  VOCAB, 
Statistics  of  Word  Tokens)  found  in  the  specified  fields  of  the 
file  the  amount  of  printed  output  may  be  very  large  unless  the 
frequently  occurring  terms  are  stopped.  Alternatively,  if  only 
some  known  terns  are  of  interest  they  can  be  put  co  a  /GO  LIST/ 
stateaent  which  will  exclude  all  ethers. 


The  width  of  the  printed  output  can  be  adjusted  using  the 
/WIDTH/  statement. 


Sannle_control  statements  for  kwic 


/ID/OCI  FROGFAfl  CATALOGUE. 

/NSW  ID/KWIC  CONCORDANCE  OP  FRGGRAH  DESCRIPTION  FIELD. 
/FIELDS/  (DESC) 

/GO  L  IST/STSTEW  ,flODEL,  FROCE£S,CCNliCL 
✓  WIDTH/  (70) 
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MOTE:  *  INDICATES  A  REQ UIBED  STATEMENT 

{*)  INDICATES  AN  OPTIONAL  STATEMENT 
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APPENDIX  B 

STATEMENT  SYNTAX  SUMMARY 

co  lu  ib  n  1 

t 

/CITATIONS/  appears  imediately 

before  the  citations 


/DELETE/  (#,#-#) 

/DEPTH/  (t) 

/DESCRIPTOR  FIELD  / (XXX X)  [%) 

/ FIEL CS/  (FLD 1 , FLD  2 , . . .  ,  LAST ) 

/FLAGS/ 

/GO  LI£T/AAAA,BB*CC,BBB.  .  . 

/ID/A  A  AAAA . 

/KEY  FIELD/  (XXXX)  (X) 

/NEW  ID/ AAAA AA . 

/NUMB  E  FS/  (  #-  #)  or  /NUMBERS/ (0) 
/ORIGI kAL/ 

/PP IN  1/  (#,#-  i) 

/PSIN1  BY  FIELDS/ 

/PRINT  BY  SUEJECTS/ 

/PRINT  NO  NUMBERS/ 

/PUNCH/ 


maximum  of  500  nunbers, 
range  counts  as  2 

minis  urn  of  13,  no  aaxiaua 

XXXX=field  label, X=any 
character  to  be  used  as 
a  delimiter 

FLD  1, etc  are  field  labels 
separated  by  comaas.  Max 
is  10  labels. 


if  a  comma  follows  a  word, 
it  is  non-triwial.  If  an 
asterisk  follows,  the  word 
is  trivial. 

maximum  text  length  is  100 
characters. 

same  as  /DESCRIPTOR 
FIEID/  execpt  [%)  is 
optional  with  the  default 
being  a  blank. 

same  as  /ID/. 

only  one  range  allowed. 


maximum  of  130  numbers, 
range  counts  as  2. 
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column  1 

♦ 

/RE?LACE/( #,♦-#)  (XXXX) *01D*HEH* 


/SEARCH/ tool can  search  formula 

/SELECT/ {#,♦-#) 

/SPACE/  (#) 

/STOP  LEVEL/ (#) 

/STOP  LIST/AAA, BB*CCC*DDDD.  .  .. 
/SYKON YMS/AA  A=BBB ,CCC  .... 
/TABS/ (1,4,#,...,#; 


#  or  #-#  *  a  citation 
number  or  a  range  of 
numbers.  XXXX  *  field 
label. 

see  section  on  SEAfiCH 
main  program. 

maximum  of  100  numbers, 
range  counts  as  2 


sane  as  /G C  LIST/ 

AAA  is  primary  word 

maximum  of  10  numbers, 
maximum  value  is  12 8. 


/VOCABUL AR Y/ AA A, B3B*CCC*DDD. . .  same  as  /GO  LIST/. 

/WIDTH/ (#)  for  printed  material, 

min=20, max* 128 

for  "punched"  material, 

min=6 ,»ax=80 


/WHITE  TAPE/ 
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APPENDIX  C 

Ca£d_ la£ut  and.  Famulag_|lj.q,.g^aii£tgi$ 


Lower  case  letters  can  be  generated  on  card  input  to 
Paaulus  by  the  use  of  certain  flag  characters  inserted  in  the 
data.  A  list  of  the  flag  characters  and  their  operation  follows, 
certain  redundancies  allow  flexibility  for  the  user. 


>  Greater  than  causes  all  letters  up  to  the  next  flag 
character  to  be  converted  to  lower  case.  Numeral  and  special 
characters  are  not  affected. 

<  Less  than  switches  off  the  conversion  of  letters  to  lower 
case  if  this  is  in  effect,  i.e.,  letters  are  left  in  upper  case 
up  to  the  next  flag. 

*  Hash  switches  case  mode.  If  lower  case  conversion  is  in 
effect,  #  switches  to  all  upper  case.  If  the  reverse  is  true, 
the  *  switches  to  the  conversion  to  lower  case. 

_  Underline  operates  the  switch  like  the  hash,  but  it 
affects  only  the  following  character.  This  is  useful  for 
capitalizing  a  siugle  character  in  a  sentence. 

!  Exclamat ion  demotes  a  flag  character  (including  ! 
itself)  to  literal  status,  i.e.,  the  following  flag  character 
does  not  operate  the  conversion  switch  in  its  usual  way,  but  is 
included  in  the  text  like  an  ordinary  character  instead  of  being 
removed  as  flag  characters  normally  are.  !  is  ignored  .f  the 
next  character  is  not  a  flag. 


\ 
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APPENDIX  D 

USING  Famulus  AT- g. Cl  5AH1AE ABEABA 


A  set  of  catalogued  procedures  (PBOCs)  have  been  written 
to  allow  easy  access  to  the  Famulus  system  on  the  UCSfi  IBB 

360-75*  The  convention  chosen  to  name  the  PBOCs  is  as  follows: 

to  read  and  create  Famulus  files  cn  3330  disk  the  PBCC  name  is  a 

•D  •  follved  by  the  program  name.  Thus  to  use  program  EDIT  the 

appropriate  PfcOC  for  disk  would  be  DEDIT.  (Note:  since  PBOC 
names  are  limited  to  8  characters.  Famulus  program  EU1TIPLT  is 
referenced  for  disk  use  by  the  proc  DMULT.) 

To  use  any  Famulus  program  you  will  need: 

1.  A  JOB  statement. 

2.  An  EXEC  statement,  with  appropriate  symbolic 
paraaaters. 

3.  Your  Famulus  control  statements  (and  input 
citations  if  creating  or  adding  to  a  file). 

4.  A  '/*'  (slasn-aster isk)  job  step  delimiter. 

The  symbolic  parameters  used  for  Famulus  are: 

1.  INVCl  -  -  Tells  Famulus  what  disk  ycu  wish  to 
access 

2.  INFILE  -  -  Gives  the  DSNAHE  of  the  file  you  wish 
to  access  (PT01F001)  . 

3.  OUT VCI  -  -  Tells  Famulus  what  disk  to  store  your 
output  on. 

4.  OUTFILE  -  -  Gives  the  DSNAHE  of  the  new  file  you 
are  creating  (FT02F001). 

5.  ADD  VOL  and  ADDFILE  -  -  Are  used  in  a  similar  way 
with  the  HEBGE  program  (FT03F001). 

6.  CITVOL  and  CITFILE  -  -  are  used  in  EDIT  when 
input  citations  are  on  tape  or  disk. 

Note  that  DSNAHES  can  be  gualified,  e.g.  • Bon. Example* . 
Each  term  in  the  gualified  name  must  be  eight  or  fewer  characters 
xn  length,  and  cannot  include  special  characters,  qualified 
names  must  be  placed  in  single  guotes. 

The  following  example  snows  the  JOB  statement  and  the  EXEC 
statement  for  creating  an  original  Famulus  file,  then 
illustrative  Famulus  control  statements. 
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APPENDIX  D 

USING  Famulus  AT  UCSB 

-  I 

EXAMPLE  OF  ORIGINAL  EDIT  RUN,  CREATING  A  NEW  FILE 


//ANYNAKE  JOB  (1234,YCURNAME) 

//  EXEC  DEDIT,CUTVOL=YCURVCL/OUTFILE=,EX AMPLE . EDIT  1 ' 
/ID/E  E I1 1 

/FIELDS/ (AU1H,TITI,IN,PJEL, KEYW, AEST, LOCT, USER ) 
/DESCRIPTOR  FIELD/ (KEYW) 

/ORIGINAL/ 

/CITATIONS/ 

. INPUT  CITATIONS  IN  Famulus  PCBKAT  HEBE... 

/* 
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20.  ABSTRACT  (Contlnua  on  ravaraa  aida  It  nacaaaary  and  Idantify  by  block  numbar) 

This  report  presents  the  system  outputs  of  the  Physical  Security  Data  Manage¬ 
ment  System.  Three  separate  outputs  are  presented:  the  Master  List,  the 
Keyword  Index  and  the  Keyword  Count.  The  Master  List  consists  of  201  indi¬ 
vidual  bibliographical  records  produced  by  the  Physical  Security  Data  Manage¬ 
ment  System.  It  consists  of  16  pages  of  computer  output.  Each  individual 
record  consists  of  a  full  bibliographical  citation,  a  keyword  list,  technical 
annotations,  relating  to  physical  security,  and  an  abstract.  The  Keyword 
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20  (continued) 

Index  consists  of  a  complete  alphabetical  listing  of  all  keywords  currently 
in  the  Data  Management  System's  controlled  vocabulary  that  can  be  used  for 
retrieval  of  bibliographical  records  stored  in  the  Master  List.  The  Keyword 
Count  is  divided  into  two  parts.  The  first  part  consists  of  an  alphabetical 
listing  of  all  keywords  currently  in  the  Data  Management  System.  Opposite 
each  keyword  is  the  absolute  number  of  times  the  keyword  appears  in  separate 
bibliographical  records  followed  by  the  percentage  of  this  frequency.  The 
second  part  consists  of  a  listing  of  all  keywords  currently  in  the  Data 
Management  System  arranged  according  to  frequency,  from  highest  to  lowest. 
Opposite  each  keyword  is  the  absolute  number  of  times  the  keyword  appears 
in  separate  bibliographical  records  followed  by  the  percentage  of  this 
frequency.  A  separate  report,  the  User's  Manual,  describes  utilization  of 
these  outputs  in  more  technical  detail. 
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SECTION  1 
MASTER  LIST 


This  section  presents  the  Master  List  of  a  sample  of  50  individual 
bibliographical  records  produced  by  the  Physical  Security  Data  Management 
System.  It  consists  of  16  pages  of  computer  output. 

Volume  II,  the  User’s  Manual,  presents  detailed  instructions  on 
★ 

how  to  use  the  Master  List. 


*  Caldwell,  J. ,  Benner,  P. ,  and  Solomonson,  D.,  Development  of  a  Physical 
Security  Data  Management  System,  Volume  II,  User's  Manual,  kRC-R -S3 1, 
Mission  Research  Corporation,  November  1979. 
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HASTES  LIST  -  CEL  BIBLICGBAPHY 


1  AC HO  BK00001 
YEAR  1976 

AUTH  Moore,  Kenneth 

TITL  Airport,  Aircraft  and  Airline  Security  (355) 

PUBL  Publisher:  security  world  Publishing  Co.,  Inc. 

KEYW  Hijacking;  Types  of  Entry,  Threats;  Air  Piracy;  Air  Cargo 
Thefts;  Physical  Security  Policy  and  Procedure;  Security 
Adainistration  6  Nanageaent;  Security  Inspection; 
Personnel;  Airports;  Facilities,  Locations;  Cargo 
Terainals 

HOI E  Skyjacking;  Ticket  Fraud;  Airport  Screening 
ABST  The  subject  of  airport,  airline  and  aircraft  security. 
Probleas  and  solutions  in  preventing  hijacking  and  in 
protecting  cargo  and  baggage  are  covered  in  detail.  Credit 
card  fraud  and  ticket  stock  security  are  thoroughly 
covered.  A  review  of  gore rnaent  regulations  and  airport 
security  is  a  useful  reference  chapter. 

2  ACNO  BK00002 
YEAR  1977 

AOTfc  Walker,  Bruce  J. ;  Blake,  Saa  F. 

TITL  Coaputer  Security  and  Protection  Structures  (143) 

PUBL  Publisher:  Dowden,  Hutchinson  and  Boss,  Inc.,  Stroudsburg, 
Pennsylvania  Perforaing  Organization:  University  of 
VAterloo 

KEYW  Coaputer  Security;  Control,  General;  Power  Supplies; 

Espionage;  Types  of  Entry,  Threats;  Inside  Jobs;  Method  of 
Entry 

ABSl  Because  the  possible  threats  to  a  coaputing  facility  and 
the  inforaation  contained  therein  deteraine  the  security 
aeasures  that  should  be  investigated,  a  survey  of  both 
internal  and  external  threats  is  included. 

3  ACNO  BK  00003 
YEAS  1973 

AUTH  Post,  Richard  S. 

TITL  Deteraining  Security  Needs  (263) 

PUBL  Publisher:  Oak  Security  Publications  Division 
KEYW  Security  Checklists;  Security  Adainistration  &  Management; 
Physical  security  Evaluation;  Security  Inspection; 
security  Personnel 

WOT K  Plant  Security;  Security  Audit;  Security  Philosophy 
ABST  Background  readings  on  security  philosophy  aethods, 

procedures  and  policy  derelopaent;  a  detailed  plan  for  the 
conduct  of  security  surveys;  a  comprehensive  checklist  for 
analyzing  security  probleas  saaple  surveys  of  a  wide 
variety  of  plants  and  facilities.  The  purpose  is  to 
provide  a  basis  for  the  conduct  of  security  systeas  in  a 
systeaatic,  logical  and  concise  aanner. 

4  ACNO  BK00004 
f EAB  1972 

AOTH  Peel,  John  D. 

TITL  Fundamentals  of  Training  for  Security  Officers  (325) 

PUBL  Publisher:  Charles  C.  Thoaas  Publisher 

KEYW  Physical  Security  Policy  and  Procedure;  Security 

Adainistration  6  Nanageaent;  Security  Manuals;  Security 
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Personnel;  Personnel 

ABST  To  supplement  or  reinforce  any  security  officer*s 

professional  knowledge.  A  collection  of  nethods  and  facts 
slanted  toward  the  practical  knowledge  of  which  the 
private  security  officer  needs. 

5  ACHO  dK  00005 
YE  AB  1^73 

AUTH  Post,  fiichard  S. ;  Kingsbury,  Arthur  A. 

rill  Security  Administration:  An  Introduction  (3t»1) 

PUBL  Publisher:  Charles  C.  Thomas  Publisher,  2nd  Ed. 

KEYW  Physical  Security  Evaluation;  Security  Adninistration  6 
Management;  Security  Manuals;  Security  Personnel; 
orientation.  Education,  and  Training;  Physical  Security 
Policy  and  Procedure 

ABST  Introduction  and  in-depth  study  of  security 

administration.  A  valuable  tool  in  determining  an 
effective  security  program.  Part  I  presents  history  and 
philosophy  of  security  and  provides  the  legal  basis  for 
security  activities.  Part  II  presents  component  parts  of 
security  function.  Part  III  presents  aplication  of 
security  components  into  integrated  programs.  Part  IV 
presents  procedures  and  techniques.  Part  V  includes 
appendices  (materials  dealing  with  security  equipment, 
shoplifting  laws,  related  security  materials),  and  a 
glossary  of  security  terminology. 

b  ACNO  OR00001 
YEAH  1978  12 

BCNO  SAND  78-0400;  AT(29-1)  789 
AUTH  Poli,  David  L. 

TITL  Security  Seal  Handbook;  (44) 

PUBL  Performing  organization:  Sandia;  Controlling  Office: 
Department  of  Energy; 

KEY w  Access  Controls;  Control,  General;  Access  Control  Systems; 

Tamper  Devices;  Alarm  Technology; 

NOTE  Security  Seals 

ABST  This  handbook  describes  the  security  seal  system 

philosophy,  provides  descriptions,  evaluation  information, 
installation  guidelines,  and  verification  instructions  for 
available  seals,  and  supplies  information  on  the 
development  of  new  seals 

7  AC  HC  O80Q002 
YEAB  1976  06 
BCNC  J-LEAA -022-74 

AUTH  Carlston,  Robert  A.;  De  Hitt,  Phillip  0.;  Hanes,  Lewis; 
Pesce,  Edward 

TITL  Crime  Prevention  Through  Environmental  Design  (40) 

PUBl  Performing  Organization:  Westingbouse  Electric  Corporation 
Controlling  Office:  Rational  Institute  of  Law  Enforcement 
and  Criainal  Justice  nonitoring  Agency:  Law  Enforcement 
Assistance  Administration 

KEYW  Architectural  Designs;  Facilities,  Locations;  Residential 
Facilities;  Environmental  Effect;  Control,  General; 

Parking  Facilities 

ABST  institute-sponsored  research  has  stodies  bow  the 
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environaent  influences  the  probleas  of  criae  and  fear  of 
criae.  Early  efforts  ia  the  United  setting  of  public 
housing  by  Mewaan  indicated  that,  by  intelligently  shaping 
our  environaent,  the  opportunities  for  crises  to  occur  can 
ce  reduced.  These  positive  signs  led  to  the  Instituted 
expand  the  scope  of  study  to  encoapass  other*  aore  ccaaon 
settings.  In  1974,  a  aajor  prograa  of  Criae  Prevention  \ 
Through  En v.ronnehtal  Design  (CPTED)  was  launched.  \ 

Besidential,  coaaercial,  and  school  environaents  and  the 
predatory,  rear-producing  crises  in  each  are  the  focus  of  \ 
this  prograa.  This  docuaent  encapsulates  the  highlights, 
concepts,  and  future  plans  of  the  CPTED  Prograa.  it  is  not 
a  progress  report,  but  rather  an  exposition. 

8  AC  NC  OHOOOOJ 
I  EAR  1979  09 

AUTb  Hoach,  Sharon;  DeLoatch,  Beatrice;  Murphy,  T.E. 

TITL  Criae  in  Service  Industries  (124) 

PU BL  Controlling  Office:  U.S.  Department  of  Coaaerce,  Doaestic 
and  International  Business  Adainistration 
KEY w  Coaputer  Security;  Burglaries;  Bobberies;  Holdups; 
Personnel  Selection;  Physical  Security  Evaluation; 

Security  Personnel 

NOTE  Credit  Card  Losses;  Bad  Checks;  Criae  Prevention 
ABST  Beport  discusses  the  iapact  of  criae  on  the  service 

sector,  the  cost  of  crises  against  business.  Provides  an 
overview  of  the  problea  as  well  as  chapters  oa  individual 
services.  Specific  vulnerabilities,  losses  and  applicable 
deterrent  aeasues  are  identified.  Coaputer  criae,  eaployee 
theft,  bad  checks  ate  discussed. 

9  AC  NO  OB00004 
YEAB  1977  04 

AOTH  Kennel,  B.P;  Holer,  B. H. 

TITL  Explosives  Control  Overview  (20) 

PUBL  Performing  Organization:  The  Aerospace  Corporation 
Controlling  Office:  Law  Enforceaent  Assistance 
Adainistration 

KEYH  Explosives;  Method  of  Entry;  Terrorist  Attacks;  Terrorist 
Threats;  Types  of  Entry,  Threats;  Access  Control  Systeas; 
Control,  General;  Identifier  Eleneats 
NOTE  Threat 

ABST  The  Explosives  Control  Overview  was  presented  at  the  1977 
Carnahan  Conference.  The  outline  includes  1)  explosives 
problen  sunnary;  2)  threat  sunnary;  3)  operational 
consideration;  4)  technical  overview;  5)  current  prograa a 
status. 

10  ACIO  OR00005 
YEAB  1973  02 

BCIO  BSD- TB- 73- *06;  P  19628-70-C-02 17 
AUTB  Papek,  Gerald  J. 

TITL  Access  Control  Models  (145) 

PUBL  Perforaiag  Organization:  Center  for  Bosonrch  ia  Confuting 
Technology,  Harvard  University  Controlling  Offices  Depaty 
for  Conaaad  6  Sanageaent  Systea,  Hg.  Electronic  Systeas 
Division  (AFSC) 


6 


MASTER  LIST  -  CEL  BX  BLICGBAFHY 


KE IV 
VOTE 


ABS1 


AC  NC 
YEAB 
EC  NC 
TITL 

PUBL 

NOTE 

ABS1 


AC  NO 
YEAB 
AUTH 
TITL 
PUBL 

KEY  V 

ABS7 


AC  NO 
AUTH 
TITL 
PUB1 

KEY  V 

NOTE 

ABST 

AC  MO 

YEAB 

AUTH 

TITL 

PUBL 


Access  Controls;  Control,  General;  Computer  Security 
Multiuser  computer  systems;  Computer  networks;  Data  bases; 
Access  control;  Bestriction  graph;  Minimum  implementation; 
Complementation  constraint 

Examines  seme  of  the  technical  aspects  of  efficiency  and 
reliability  which  are  affected  by  access  ccntrcl  in 
complex,  multiuse  data  bases.  A  model,  its  theoretical 
basis,  and  algorithms  reprsentations  of  access  control 
relationships  for  a  number  of  conditions  are  presented. 

The  issue  of  reliability  in  the  control  of  access  to 
information  in  a  shared  data  base  is  also  discussed. 

OTOOOD4 
1977  01 
DA  PAM  IOd-1 

Index  of  Army  Motion  Pictures  and  Belated  Audio-Visual 
Aids  (292) 

Performing  Organization;  Headguarters,  Department  of  the 
Army 

Motion  Picture  Index;  Army  Motion  Pictures;  Audio-Visual 
Aids 

DA  PAM  108-1  is  the  official  DA  catalog  and  contains 
complete  information  of  all  audiovisual  products  which  are 
available  for  distribution. 

OT00005 
1977  07 

Wallach,  Charles;  Ricci,  Roy  Dr. 

Security  Netal  Detection  Systems  (6) 

Publisher;  American  Society  for  Industrial  Security 
Controlling  Office:  INTEXT  Inc. 

Alarm  Technology;  Metal  Sensors;  Alarm  Sensors; 
Surveillance  Methods;  Control,  General;  Weapons  Detection 
Discusses  passive,  magnetometer  metal  detectors;  active 
continuous  wave  metal  detectors  and  pulsed  field  systems. 

A  review  of  how  to  select  the  most  effective  detector 
related  to  particular  applications. 

,/ 

OTOOOOb 

Keeney,  Harry  W. ;  Kellem,  C. 

Directory  of  Security  Product  Manufacturers;  (25) 
Controlling  Office:  National  Crime  Prevention  Institute, 
School  of  Police  Administration 

Builders  Hardware;  Builders  Hardware;  Manufacturers 
Association;  Alarm  Eguipment  Distributors 
Security  Products;  Security  Product  Manufacturers; 

Security  Eguipment 

Directory  of  Security  Products  Manufacturers 

OT00007 

1972 

Hudiburg,  Everett;  McCoy,  Carl  E 

Forcible  Entry,  Rope  and  Portable  Extinguisher  Practices 
(179) 

Publisher:  Fire  Protection  Publications,  OK  State 
University  Controlling  Office:  International  Fire  Service 
Training  Association 
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KEYS  Forced  Entry  Methods;  Method  o £  Entry;  Forced  Entries; 

Types  o£  Entry/  Threats;  Breaching  Aids;  Boots;  Windows; 
Doors;  Nalls 

ABST  The  manual  deals  with  building  construction  and  how  to 
force  entrance  into  buildings,  fire  service  rope 
practices,  and  portable  fire  extinguishers.  Bevised  in  its 
present  fora  according  to  the  rejuirenents  presecribed  by 
an  editorial  committee  of  the  International  Fire  Service 
Training  Assoc. 

15  AC  BO  OTQ0009 
YEAH  1975 

A JTH  Saxon,  Kurt 

TITL  Fireworks  an  1  Explosives  like  Granddad  Used  to  Make  (61) 
KEYW  Explosives;  3reaching  Aids 

ABST  Late  1800's  guide  to  hoaenade,  handnade  explosives, 

fireworks,  chemicals  and  combs.  Current  infocnatiou  on 
boab  and  explosive  handling  and  protection. 

16  AC MO  PC00005 

TITL  Panic  Deadbolt  Lock-Exitguard  (3) 

PUBL  Publisher:  Alarn  Lock  corporation 

KEYH  Lock  Technology;  Panic  Bolts;  Bolts;  Dead  Bolts;  Dead 
Locks 

ABST  Exitguard  provides  a  sturdy  deadbolt  in  addition  to  a 

patented  deadlatch  to  resist  intrusion,  yet  it  opens  with 
finger  tip  pressure  if  eaergency  exit  is  required. 

17  ACHC  PC00006 
HCMO  85 

X1TL  Digital  Key,  Digital  Access  Control  Systens  (5) 

PUB L  Controlling  Office:  ASC  Security  Systens,  LTD. 

KEYH  Access  control  Systens;  Entry  Control  Devices; 

NOTE  Digital  Keys 

ABST  Illustrated  catalog  of  ASC  line  of  digital  access  control 
systen  equipment  and  devices.  Price  list  and  product 
description  included. 

18  ACNO  PC00007 

TITL  A.P.D.  Security  Systens  (4) 

PUBL  Perforning  Organization:  A.P.D.  Autonatic  Parking  Devices, 
Inc. 

KEYH  Access  Controls;  Control,  General;  conbinatioo  locks;  Lock 
Technology;  Lock  Devices;  Access  Control  Systens 
ABST  Product  literature  includes  A.D. P.  security  locks, 

recycling  locks,  code  conbination  locks,  card  leeks,  and 
digital  print  reader. 

19  ACHC  PC00008 

YEAB  1974  09 

AUTH  Arrow  Lock  Corporation 

TITL  Heavy  Duty  Mortise  Lock  Sets  (11) 

KBYH  Lock  Parts;  Mortise  Cylinders;  Dead  Bolts;  Inner  Plates 
NOTE  Dead  Lock;  Knobs 

ASST  The  nortise  lock  is  designed  for  heavy  use  in  schools, 
hospitals,  and  connercial  buildings.  Product  literature 
discusses  and  illustrates  variety  of  nortise  locks  and 
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ACNC 
TITL 
PUBL 
KE  YU 
ABST 


ACNO 
YEAB 
AU1H 
riTi 
PUBL 
K  EYB 


MOTE 

ABST 


ACNO 

YEAB 

AUTH 

TITL 

PUBL 

KEIU 


NOTE 

ABGT 


corresponding  attachments  and  accessories. 

PC00010 

Best  Security  S ysteas-Padlocks  (3) 

Publisher:  Bast  Loch  Corporation 
Lock  Types;  Lock  Technology;  Padlocks 

Discusses  parts,  accessories  and  options  for  all.  Best 
padlocks.  Types  and  sizes  of  padlocks  available  are  also 
discussed. 

PE00001 
1979  02 

Tinnon,  David  B;  Halevy,  David 

Strike  leans;  Playboy;  Volume  26;  No.  2  (10) 

Publisher:  Playboy  Enterprises,  Inc. 

Terrorist  Attacks;  Terrorist  Threats;  Hijacking;  Air 
Piracy;  Forced  Entry  Methods;  Methods  of  Entry;  Breaching 
Aids;  Bugging;  Security  Administration  &  Management; 
Personnel  selection;  Facilities;  Airports 
Project  Blue  Light;  Black  Berets;  Small  Arms;  Poreign 
Strike  Forces 

Presents  an  inside  look  at  Commando  organizations  that 
nave  been  formed  specifically  to  ccnbat  terrorists, 
particularly  hijackers.  Describes  Project  Blue  Light,  the 
US  180  man  antiterrorist  force  patterned  on  British, 
Israeli  and  Uest  German  units.  Project  Blue  light 
training  and  recruitment  briefly  described.  Foreign 
antiterrorist  organizations  are  described,  including  the 
British  Special  Air  Services,  the  Uest  German  Group  Nine 
of  the  of  the  Border  Guard,  and  the  Israeli  269th 
Headquarters  Reconnaissance  Regiment.  A  sidebar  presents 
a  brief  evaluation  of  terrorist  and  antiterror ist  small 
arms.  Principal  purpose  of  the  article  supports  the  claim 
that  the  US  has  am  antiterrorist  strike  force. 

PE00002 
1979  10 

Toth,  Robert  C. 

Fires  Afloat,  Arson  Cases  Signal  Stormy  Seas  for  Navy;  Los 
Angeles  Times;  (2) 

Los  Angeles  Times 

Types  of  Entry,  Threats;  Arson;  Vandalism;  Methods  of 
Entry;  Inside  Jobs;  Personnel  Selection;  Physical  Security 
Policy  and  Procedure;  Facilities;  Ships  and  Boats 
Naval  Investigative  Services  1979  data  on  12  ship  fires, 
$4.25  million  damage. 

Twelve  fires  have  broken  out  aboard  12  U.S.  Navy  ships  in 
1979  causing  14.25  million  in  damage  according  to  the 
Naval  Investigative  Service.  The  NIS  has  drawn  a  composite 
profile  of  a  Navy  arsonist  based  on  the  traits  of  15 
suspects.  Outbreak  of  arson  more  serious  than  ether 
services.  In  1978,  the  Navy  had  128  cases  of  suspected  or 
confirmed  arson.  The  Army  had  49  cases  causing  $33,000 
worth  of  damage  and  the  Air  Force  bad  81  fires  causing 
$78,640  in  damage.  Explanations  for  the  outbreak  are 
■ultiple.  Social  probless  of  society  are  transplanted  on 
ships.  Navy  has  higher  disertion  rate  than  other 
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Services.  Ships  are  on  station  longer.  There  ate  tenet 
ships.  There  is  no  evidence  that  the  problems  are  racial, 
he  current  problem  is  unlike  the  race  riots  of  1970-72  in 
the  Pacific  Fleet. 


23  ACNO 
YEAR 
AUTH 

IITL 

PUBL 

KEYW 


NOTfc 

ABST 


PE00003 
1977  03 

Mendelson,  Fred;  Kuhns,  Boger;  D’Addario,  Francis; 
Anderson,  Edvar  ';  Parker,  Brian 
Security  Management;  Vol.  21,  No.  1 

Publisher:  American  Society  for  Industrial  Security 
Photo  Electric  Alarm  Systems;  Alarm  Technology;  Detection 
Systems;  Identifier  Elements;  Espionage;  Types  of  Entry, 
Threats;  Security  Inspection;  Security  Administration  6 
Management;  Physical  Security  Planning 
Photo  I. D.  Systen;  Industrial  Espionage 

"The  Great  {Photo  ID)  card  Game"  by  Mendelson,  F. ;  "Photo 
Identification"  by  Kuhns,  B. ;  "Development  of  Security 
Self  Sufficiency:  Survival  of  the  Urban  Betailers"  by 
D'Addario,  F.J. ;  "A  Study  of  Industrial  Espionage:  Part 
II"  by  Anderson,  Edvard 


24  ACNO 
YEAB 
TITL 
PUBL 
KEYN 


NOTE 

ABST 


25  ACNO 
TEAB 
TITL 
PUBL 
KEY8 

NOTE 

ABST 


PE00004 

1978  11 

Security  Surveyor;  fol.  4,  No.  4 
Publisher:  Victor  Green  Publications  Ltd. 

Residential  Facilities;  Facilities,  Locations;  CCTT 
Surveillance  Systems;  surveillance  Methods;  Control, 
General;  Vandalism;  Types  of  Entry,  Threats; 
Electromechanical  Devices;  Alarn  Technology;  Electronic 
Security  Systems 

Community  Crime  Prevention;  Domestic  Besidential  Security 
Articles  in  this  issue  include,  "Surveying  Domestic 
Residences";  "CCTV  and  It's  Applications";  "Crime  and  the 
Community";  "Electronics  for  the  Security  Man";  "IF  SSEC 
•79  -  Conference  Program" 

PE0Q005 

1979  01 

Security  Distributing  and  Marketing;  Vol.  9,  No.  1 
Publisher:  Security  World  Publishing  Co.,  Inc. 

UL  Listed;  UL  Certificated;  Control,  General;  Ultrasonic 
Preguency;  Alarm  Technology 
Landlord  Liability 

"Burglar  Alarm  Certification"  by  Oppen,  Lary;  "ISC/Los 
Angeles  1979"  and  "Overcoming  Ultrasooic  Noise"  by 
Mioduszewski,  Frank 


26  ACNO 
TEAS 
BCNO 
AUTH 
TITL 

PUBL 


BD00001 
1977  05 
2209 

Fite,  B.  A. 

Commercial  Perimeter  Intrusion  Detection  Equipment 
Evaluation  (117) 

Performing  Organization:  Counter  Intrusion  Laboratory, 
Intrusion  Detection  Division,  DBOMB-XI;  U.S.  Amy  Mobility 
Equipment  Research  and  Developnent  Connand  Controlling, 

10 
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Office;  Counter  Intrusion  Laboratory 
KE YU  False  Alarms;  Active  Intrusion  Sensors;  Area  Sensor; 

Interior  Perimeter  Protection;  Fence  Alarms;  Intrusion 
Alarm  Data;  Intrusion  Detection  Alarms;  Electromagnetic 
Interf erance;  Access  Controls;  Infrared  notion  Detectors; 
Microwave  Alarm  Systems 

ABST  Describes  the  test  program  performed  by  Meradcom  to 

dotermin»?  the  performance  and  reliability  characteristics 
of  a  number  of  commercially  available  outdoor  perimeter 
sensors.  Each  sensor  was  subjected  to  detection,  nuisance 
alarm,  electromagnetic  interference,  temperature  and  salt 
spray  tests  to  determine  effectiveness. 

27  ACNG  RDJ0002 
YEAR  1 978  03 
HCNC  2237 

AUTH  Garrett,  Uilliam  C. 

TITL  Infrared  Motion  Sensor  Evaluation  { 1  a 7; 

PUBL  Performing  Organization;  Counter  Intrusion  Laboratory, 

Intrusion  Detection  Division,  DHGHE-X1 ;  O.S.  Army  Nobility 
Equipment  Research  and  Development  Command  Controlling 
Office:  Counter  Intrusion  Laboratory 
KEYW  Infrared  Motion  Detectors;  Motion  Sensors;  Active 

Intrusion  Sensors;  Intrusion  Alarm  Data;  Alarm  Systems  - 
Detection  systems;  Intrusion  Detection  Alarms;  Physical 
Security  Evaluation;  Program  Testing 
ABST  Describes  the  test  program  performed  by  MEBADCOM  to 

determine  the  performance  and  reliability  of  Model  19-115 
Infrared  Intrusion  Sensor.  Three  commercial  infrared 
sensors  were  included  in  the  test  program  to  establish  a 
baseline.  Each  was  subjected  to  detection,  nuisance 
alarms,  electrocagnetic  interference  and  temperature  to 
determine  ef fectiveness.  Detailed  performance  data  is 
included. 

28  ACNG  RD00003 
YEAR  1977  10 

8CHC  DOD  5220.22-M 

TITL  Industrial  Security  Manual  for  SafeGuardimg  Classified 
Information  (18) 

PUBL  Performing  organization:  Sargent  and  Greenleaf,  Inc. 

Controlling  office:  Department  ot  Defense 
KB YU  Dead  Bolts;  Combination  Lock  Parts;  Combination  Locks-OL 
Designations;  Padlocks;  Electric  Locks;  lock  Technology 
ABST  Excerpts  from  DOD  5220. 22-M  Industrial  Security  Manual 
intented  to  assist  in  selection  of  locks  for  maximum 
security  application. 

29  ACMO  HD00004 

YEAR  1978  10  1 

BCMQ  OPNAVINST  5510. 45C 

TITL  Revision  of  O.S.  Navy  physical  Security  Manual  (197) 

PUBL  Controlling  office:  Department  of  the  Navy,  Chief  of  Naval 
Material 

KEXM  Security  Infractions;  Physical  Security  Policy  and 
Procedure;  Security  Manuals;  Security  Personnel; 

Classified  Material;  Physical  Security  Planning 

11 
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ABST  Draft  revision  to  the  U.S.  Navy  Physical  Security  Manual. 

30  ACNO  BD00005 
TEAS  1978  12 

BCNC  OPNAVINST  5510. IP 

TITL  Information  Security  Program  Begulation  (304) 

PUBL  Controlling  Office:  Department  of  the  Navy,  Office  of 
Chief  of  Naval  Operations 

KEXU  Security  Infractions;  Physical  Security  Policy  and 
Procedure;  Security  Manuals;  Security  Personnel; 

Classified  Material;  Physical  Security  Planning; 
Classification  Management;  Classified  Material 
aeproduction ;  Classified  Transmissions 
Ati si  The  instruction  provides  all  Department  of  Mavy  activites 
and  personnel  with  Department  of  Defense  and  Navy 
regulations  and  guidance  for  classifying  and  safeguarding 
classified  information. 

31  ACNO  RD000Q6 
YEAB  1979  08 

BC NO  NAVFAC  Y 0995- 0 1- 005- 251 

TITL  Window  and  Vent  Barrier  Evaluation;  (49) 

PUBL  Performing  Organization:  Sandia  Laboratories  controlling 
office:  Dept  of  Defense  Monitoring  Agency:  Dept  of  the 

Navy 

KEYH  windows;  Forced  Entry  Methods;  window  Guards;  Breaching 
Aids;  Barrier  Penetration; 

NOTE  Vents; 

ABST  A  nunber  of  forcible  entry  attacks  were  made  at  Sandia 
Laboratories  against  a  variety  of  specimens  designed  to 
replicate  barriers  specifed  in  Navy  and  DOD  directories. 

In  addition  to  the  commonly  specified  DOD  designs,  4  CEL 
selections  (7/8"  diameter  tool  resistant  and  mild  steel 
jailbars,  riveted  steel  grating,  grip  strut  panels)  were 
also  tested. 

32  ACNC  BD00026 
YEAB  1975  05 

BC  NC  ONI-CP-6 1-5-75 

TITL  Damage  Incidents  Affecting  the  Department  of  the  Mavy  (39) 
PUBL  Performing  Organization:  Naval  Investigative  Service, 

Naval  Intelligence  Command 

KEIh  Ships  and  Boats;  Facilities,  Locations;  Port  Facilities; 

Arson;  Types  of  Bntrj,  Threats;  Vandalise 
ABST  Contains  cronological  sunnaries  of  incidents  of  damage 

during  1  October  through  31  December  1974,  affecting  the 
Department  of  the  Navy  and  investigated  by  the  Naval 
Investigative  Service.  There  were  167  incidents  of  danage 
during  the  fourth  quarter  of  1974,  of  which  149  cases  were 
closed. 

33  ACNO  BD00029 
YEAS  1977  04 
ECHO  2208 
AUTH  Fite,  B.  A. 

TITL  Joint  Services  Perineter  Barrier  Penetration  Evalnation 
(63) 


12 
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?UBL  Perforaing  organization:  Counter  Intrusion  Laboratory, 

Intrustion  Detection  Divison,  DBOHE-XI,  U.S.  Army  nobility 
Equipnent  Research  and  Development  Coaaand;  Controlling 
Office:  Counter  Intrusion  Laboratory,  DRONE-II,  O.s.  Amy 
Nobility  Eguipaent  Research  and  Developaent  Coanand 
KEYtf  Breaching  Aids;  Nethod  of  Entry;  Barrier  Penetration; 
Pences;  Builders  Hardware 

MOTE  Barrier  Penetration;  Chainlink  Configuration;  Barbed  Tape 
Barriers 

ABST  Descrioes  the  evaluaticn  of  various  chain  link  fences  and 
barbed  tape  barriers  to  deternine  their  effectiveness.  20 
difference  fence  and  barbed  tape  barriers  were  erected  and 
evaluated  against  a  variety  of  covert  and  overt 
penetration  methods. 

34  AC  NO  RD00030 
Y EAR  1977  06 

BC NO  NBIR  77-12262;  DNA  1ACRO  77-805 

AUTH  Moore,  B.T.,  Carpenter,  R.J.,  Koenig,  A.  L. 

T1TL  Computerized  Site  Security  Monitor  and  Response  System 
(44) 

PUSL  Performing  organization:  National  Bureau  of  Standards, 

Department  of  Commerce  Controlling  Office:  Defense  Nuclear 
Agency 

KEYW  CCTV  Surveillance  Systems;  Control,  General;  Intrusion 
Alarm  Data;  Alarm  Technology;  Computer  Security; 

Electronic  Security  Systems;  Sensor  Signals;  Alarm 
Monitors;  Sound  Sensors 

NOTE  Adversary  Scenarios;  Automated  Response  Systems; 

Distributed  Processing;  Monitoring  Systems;  Physical 
Security;  Sensor  Systems 

ABST  The  Computerized  Site  Security  Monitor  and  Response  System 
(CSSHRS)  was  conceived  as  an  integrated  state-of-the-art, 
computer-based  system  to  enhance  and  improve  the  overall 
phsyical  security  of  storage  sites  for  special  meapons  and 
materials.  Many  of  the  attributes,  capabilities,  and 
features  developed  during  the  course  of  work  ace  set 
forth.  Some  of  the  alternatives  are  identified  as  are 
areas  where  additional  work  will  be  necessary  to  reach 
clearly  identifiable  and  attainable  objectives  necessary 
to  complete  the  system  definition. 

35  ACNO  RL0000I 
YEAR  1976  11 

ECNC  111-1238-911;  GDC-EBR- AN- 1134 
AUTH  Campbell,  M.D.;  O'Barr, G.L. ;  Pynchon,  G. E- 
TIT1  Developaent  of  Ballistics  Test  Pacility  and  Evaluation  of 
Vulnerability  of  Aircraft  Materials  (46) 

POBL  Performing  Organization:  General  Dynamics,  Materials 
Research  Group,  Convair  Division  Controlling  Office: 
General  Dynanics 

KEYH  Armored  Doors;  Builders  Hardware;  Armor  Plates;  Bullet 
Proof;  Hardware  Proper ties-Coaposition ;  Thickness; 
Airports;  Facilities,  Locations 
NOTE  Ballistics  Test  Facility 

ABST  An  in-plant  facility  was  constructed  at  General  Dynanics 

Convair* s  Kearny  Mesa  Site  for  the  purpose  of  studying  the 
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behavior  of  aircraft  armor  materials  and  structures  when 
impacted  by  military  projectiles  up  to  caliber  .50  and 
secondary  fragments,  while  subjected  to  service 
environments.  The  facility  was  designed  to  peewit  testing 
of  structural  materials,  full-scale  structural 
configuration  test  sections,  and  lightweight  araor 
specimens.  Following  an  initial  program  to  evaluate 
performance  of  the  facility,  the  facility  was  used  to 
study  the  damage  to  7075-1651  aluainua  plates,  and  the 
survivability  of  CL-84  power  train  shafting  when  subjected 
to  caliber  .50  AP  M 2  impacts  under  a  simulated  service 
condition. 

36  AC  NC  HL00002 

YEAR  1971  10 

RCNC  0P-44P,  Set.  10  131P44 

TITL  Incidents  of  Malicious  Damage  of  Sabotage  in  The  Navy  (66) 
POOL  Performing  organ ization;  Physical  Security  Organization 
Study  and  Planning  Croup  Controlling  Office:  Chief  of 
Naval  operations.  Department  of  the  Navy  Monitoring 
Avjency:  Deputy  Chief  of  Naval  Operations 
K E  i  w  Physical  Security  evaluation;  Security  Administration  6 

Management  ;  Physical  Seem  ity  Planning;  Physical  Security 
Review  committees;  Physical  Security  Policy  ui.a  Procedure 
Ah.il  la  reference  to  an  examination  oy  the  Navy  Physical 
Seoul ity  Organic liton  on  the  need  for  a  centralized 
organization  to  establish  policy,  provide  guidance, 
develop  equipment  and  coordinate  the  man;  lacits  involved 
in  physical  security.  The  Advisory  Committee  members 
unanimously  approved  the  conclusions  and  recommenda t ions 
of  the  Study  group,  except  for  the  location  for  the  new 
organization.  Three  potention  locations  are  presented  for 
review. 

37  AC  NC  KL0000J 
YEAR  1972  02 

TITL  Technical  Evaluation  of  Holobeam  SC20:  Secure  Personnel 
Access  Control  System  (14) 

POOL  Performing  Organization:  Technical  Branch-Division  of 
Security  Atomic  Energy  Commission 
KEYW  Personnel;  Security  Adain istr ation  &  Management;  Access 
Control  Systems;  Control,  General;  Access  Controls;  Card 
Exchange  Systems;  Monitoring  Stations;  Alara  Technology; 
Identifier  Eleaents;  Remote  Station  Alara  System 
ADST  The  Holobeaa  Secure  Personnel  Access  Control  System 

(SPACS)  Model  SC-20  is  described  as  a  systea  providing 
positive  identification  of  authorized  personnel  as  a 
condition  of  allowing  thea  access  to  a  protected  area.  The 
systea  consists  of  four  aajor  components:  access  card, 
card  reader  console,  reaote  unit  and  connector  cable. 

J8  AC  NO  RL00004 
YEAR  1977 
RCNO  TN-14&9 
AdTH  Gray,  K.  o. 

TITL  Externally  Generated  Light  (SQL)  Systems  for 
Hyper  bar ic/Hypobaric  Chambers  (51) 

14 
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PUBL  Performing  Organization:  Civil  Engineering  Laboratory, 
Naval  construction  Battalion  Center  Controlling  Office: 
Civil  Engineering  Laboratory,  Naval  Construction  Batallion 
Center  Monitoring  Agency:  Naval  Facilities  Engineering 
Command 

K Elf M  Lighting;  Builders  Hardware;  Interior  Lighting;  Infrared 
Motion  Detectors 

NOTE  Diver;  Recompression  Chambers;  Hyperbaric  Chamber 
AQST  Lighting  systems  for  hyper taric/hypobaric  chambers  are 
described.  Mehtods  of  interior  illumination  without 
introduction  of  any  potential  fire  source  in  the  chamber 
are  presented.  The  systems  utilize  light  generated  ouside 
of  the  chamber  environment,  filtered  for  reduction  of 
infrared  radiation,  and  then  introduced  through  either 
large  or  small  transparent  hull  penetrations. 

39  ACNO  BL00005 
YEAB  1976  06 

TITL  Automatic  Vehicle  Monitoring  Systems  Study,  Report  of 
Phase  0;  (97)  Vol.  2 

PUBL  Performing  organization:  Jet  Propulsion  Laboratory, 

California  Institute  of  Technology  Controlling  Office: 
National  Science  Foundation 

KEY w  Monitoring  Stations;  Alarm  Technology;  Sensor  Signals; 

Vehicle  Traffic  Control;  Control,  General 
ABST  A  set  of  planning  guidelines  is  presented  to  help  law 

enforcement  agencies  and  vehicle  fleet  operators  decided 
which  automatic  vehicle  monitoring  (AVM)  system  could  best 
meet  their  performance  reguireaents.  Improvements  in 
emergency  response  times  and  resultant  cost  benefits 
obtainable  with  various  operational  and  planned  AVM 
systems  may  be  synthesized  and  simulated  by  means  of 
special  computer  programs  for  model  city  parameters 
applicable  to  small,  medium  and  large  urban  areas.  Design 
characteristics  of  various  AVM  systeas  and  the 
iapleaentation  reguireaents  are  illustrated  and  costed  for 
the  vehicles,  the  fixed  sites  and  the  base  eguipnents. 
Vehicle  location  accuracies  for  different  BF  links  and 
polling  intervals  are  analyzed.  Actual  applications  and 
coverage  data  are  tabulated  for  seven  cities  whcse  police 
departments  actively  cooperted  in  the  JPL  study.  Volume  1 
of  this  Report  is  the  Executive  Summary.  Volume  2  contains 
the  results  of  systems  analyses. 

40  ACNC  BL00006 
YEAB  1972  12 
BCNO  74-09 

AUTH  Samuels,  David  if.;  Thein,  Brenda  K.;  Shank,  B.B. 

TITL  operational  Tests  of  the  Coherent  Optical  Fingerprint 
Identification  Systen  (COFIDS)  (30) 

PUBL  Performing  Organization:  US  Amy  Land  warfare  Laboratory, 
Aberdeen  Proving  Ground  Controlling  Office:  Departnent  of 
Defense 

KEYH  Fingerprint  Identification  Systens;  Control,  General; 

Access  Control  Systens;  Entry  Control  Devices 
ABST  This  system  employs  the  technigues  of  optical  holography 
to  encode  fingerprint  details  and  store  such  infornation. 
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AC  MO 
AUTH 
TITL 

PUBL 


KEYW 


AsiST 


ACNO 

YEAB 

ECHO 

AUTH 

TITL 

PUBL 


KEYW 

ABST 


with  high  data  density,  on  miniature  photographic  files. 
Identification  is  perforied  by  comparing  fingerprints  with 
the  hologram  using  optical  cross-correlation.  The  test, 
involving  over  100  people  of  USALWL,  was  carefully 
designed  and  instrumented  to  provide  complete  statistics 
of  performance.  The  evaluation  indicates  that  the  system 
provides  a  highly  foolproof  means  of  personnel 
identification. 

RL00007 

Thompson,  J.  H.  ;  Gray,  K.O.;  Self,  H.L.;  Brier,  F.W. 
Physical  Security:  Technical  Memoranda  and  Progress 
Reports 

Performing  organiza tion:  Civil  Engineering  Lac  Controlling 
Office:  Naval  Electronic  Systems  Eng.  Center,  Naval 
Facilities  Eng.  Command,  Naval  Sea  Systems  Command,  DN A, 
Mechanical  and  Electrical  Eng.  Dept.,  CEL 

Perimeter  Alarm  Systems;  Lock.  Devices;  Sensor  Status;  Lock. 
Technology;  Active  sensors;  Passive  Sensors;  Weapons; 

Armor  Plates;  Bullet  Proof;  Physical  Security  Planning; 
Access  Controls;  Physical  Security  Evaluation 
Compilation  of  research  and  development  projects  with 
reference  to  physical  security.  Research  was  performed  by 
CEL.  Includes  the  following  reports:  "Evaluation  of  a 
Perimeter  Public  Address  Systea  for  Naval  Weapons 
Station",  "Phys.  Sec.  RDT  and  E  Work  Unit  Prog.  Report  No. 
2",  "Evaluation  of  Emergency  Door  Locking  Device  Shear 
Pin",  "Sum  Report-Security  Eng.  and  Consultation 
Services",  Sum  Report-Ballistic  Protection  for  Weapons  in 
transit",  " DN A  Magazine  Dcor  Relocking  Hardware 
Development",  "Status  of  the  Phys.  Sec.  Info.  Center", 
"Field  Review  of  Opening  Control  Hardware",  "Areas  in 
Phys.  Sec.  requiring  HOT  and  E",  "High  Sec  Lock  Hasp 
Evaluation",  "Phys.  Sec.  BDT  and  E.  Prog  Sum  Report", 
"Architectural  Details  Sum.  Heport",  "DN A  Magazine  Door 
Relocking  Hardware  Development". 

RL00008 
1979  05 
77-07R 
Gray,  K.  0. 

Key-operated  Security  Locks  and  Hasps  (4) 

Performing  organization:  civil  Engineering  Laboratory, 
Naval  Construction  Battalion  Center  Controlling  Office: 
Department  of  the  Navy 

Lock  Parts;  Lock  Technology;  Hasp  Locks;  Shackle  of 
Padlock 

Report  on  the  results  of  an  investigation  concerning  the 
constituents  of  high,  nedium  and  low  security  locks. 
Military  specification  HIL-P-43607D  sets  the  highest  level 
of  performance  for  day  of  the  key  operated  padlocks 
specified  for  use  by  DOD  and  MIL-H-439511  for  the 
corresponding  hasp.  MIL-P-43951  qualifies  nediun  security 
and  MIL-P-  17802D  designates  the  low  security  padlock. 


ACNC  BL00009 
YEAB  1977  12 
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hCNC  76-08B 

TITL  High  Security  Hasps  for  naval  Environments  (3) 

PDBI  Performing  Organization:  civil  Engineering  Laboratory 
Controlling  office:  Department  of  lavy 
KEYH  Hasps;  Lock  Technology;  Ships  and  Boats;  Facilities, 

Locations;  Port  Facilities;  Waterfront  Areas;  Lock  Parts; 
Shackle  of  Padlock 

NOTE  High  Security  Hasps;  Naval  Environnents 

ABST  The  full  potential  of  the  Navy's  Shrouded  Shackle  High 

Security  Padlock  to  protect  armories,  aaauaitioa  storage 
aagazines  and  other  sensitive  spaces  can  only  be  realized 
if  it  is  aatched  with  an  egually  good  hasp,  door,  door 
attachment  systen  and  structure. 

44  ACNO  HT00Q01 
YEAB  1972 

BCNO  ANSI  A 156.  2-  1972 

AUTH  Aaerican  National  Standards  Institute,  Inc. 

TITL  Aaerican  National  Standard  Lock  and  Lock  Tria  (23) 

PUBL  Publisher:  Builder's  Hardware  Manufacturers  Association; 
Perforaing  Organization:  Aaerican  National  Standard 
Institute,  Inc.;  Controlling  Office:  Builders  Hardware 
Manufacturers  Association 

KEYH  Lock  Types;  Lock  Technology;  Bore- in-Locks;  Mortise  Locks; 
Dead  Locks 

ABST  A  sectional  classification  systea  to  recognize  the 
diversity  in  the  general  classif ication  of  builders 
hardware.  Includes  general  reguireaents  and  inforaatin  on 
aortise,  preasseabled,  integral  and  bored  locks  and  tria. 

45  ACNO  BT00002 
YEAN  1973  12 

AUTH  Newaan,  Oscar 

TITL  A  Design  Guide  for  laproving  Besidential  Security  (75) 

PUBL  Perforaing  Organization:  The  Center  for  Besidential 

Security  Design  Controlling  Office:  U.S.  Department  of 
Housing  and  Urban  Development  Monitoring  Agency:  Office  of 
Policy  Development  and  Research,  Division  of  Building 
Technology 

KEYH  Doors;  Builders  Hardware;  Hardware  Properties;  Besidential 
Facilities;  Alarm  Technology;  Personnel;  Security 
Adainistration  &  Management;  Personnel  Selection;  Physical 
Security  Planning;  Physical  Security  Evaluation;  Lock 
Devices;  control.  General;  Access  Coatrol  Systens; 
Facilities,  Locations;  Electronic  Security  Systems 
NOTE  Besidential  Security;  Defensible  Space 
ABST  Pour  approaches  for  improving  residential  security  are 

emphasized:  (1)  creation  of  a  fortification  with  limited 
and  controlled  access  points;  (2)  subdivision  of  a  large 
residential  conplex  into  smaller  components  so  each  nay  be 
controlled  naturally  by  a  small  number  of  residents;  (3) 
relocation  of  a  particularly  vulnerable  group  into  a  safe 
area  occupied  by  that  group  alone;  (4)  inundation  of  a 
residential  conplex  by  security  personnel. 


46  ACNO  BT00003 
YEAB  1977  09 
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47  ACMO 
BC  80 
TITL 
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REIN 
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48  ACMO 
YEAR 
BCMO 
TITL 
PUBL 


KETH 


ABST 


SAND77-1033:  AT  <29-1)  789 
Entry  Control  Systems  Handbook 

Perforaing  Organization:  Sandia  Laboratories;  controlling 
office:  Division  of  Safeguards  and  Security;  Monitoring 
Agency:  Departaent  of  Energy 

Entry  Control  Devices;  Control,  General;  Access  Control 
Systeas;  Access  Controls;  Personnel  Becogaition  Methods; 
Metal  Sensors;  Alara  Technology 

Special  Nuclear  Materials  Monitors;  Metal  Detectors; 
Explosives  Detectors;  Package  Search  Systeas 
An  entry-control  systea  functions  in  a  total  Physical 
Protection  systea  to  alio*  the  aoveae at  of  authorized 
personnel  and  aaterial  through  noraal  access  routes,  yet 
detect  and  delay  unauthorized  aoveaent  of  personnel  and 
aaterial  froa  controlled  areas.  The  aaterial  in  this 
handbook  is  primarily  restricted  to  those  eleaents  of  a 
safe  guards  systea  related  to  entry-control  technology. 
All  known  entry-ccntrol  equipment  has  been  listed  in  this 
handbook  for  coapleteness. 

BT00004 
NAVEDTBA  91424 

Nonresident  Career  course  -  Naster-at- Aras  (88) 

Publisher:  Naval  Education  and  Training  Support  Coaaaad; 
Perforaing  Organization:  Naval  Education  and  Training 
Support  Coaaand 

Physical  Security  Policy  and  Procedure;  Security 
Adainistration  &  Nanageaent;  Personnel;  Military 
Personnel;  orientation.  Education,  and  Training;  Physical 
Security  Policy  and  Procedure;  Security  Manuals 
The  Haster-at- Arms  non-resident ial  career  course  is  an 
independent  study  progran  designed  to  teach  skills 
required  for  advanceaent  in  the  N-A  rating. 

BT00005 

1974 

NAVEDTBA 

Haster-at-Aras  -  Training  Manual  (287) 

Publisher:  Naval  Education  and  Training  Support  Coaaand 
Perforaing  Organization:  Naval  Education  and  Training 
Support  Coaaand 

Physical  Security  Planning;  Physical  Security  Policy  and 
Procedure;  Security  Adainistration  6  Hanageaent;  Security 
Personnel;  Orientation,  Education,  and  Training;  Security 
Infractions;  Security  Manuals 

Manual  is  designed  to  train  HAS  to  be  able  to  plan, 
supervise,  and  perfora  security  duties  afloat  and  ashore, 
including  investigation,  interrogation,  apprehension,  and 
correction.  This  Manual  is  designed  to  be  self 
instructional. 
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Brooks,  J.L. 

Heat-Activated  Alara  Systea  for  Railroad  Boxcars  Carrying 
Explosives  (27) 
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Performing  organization:  Civil  Engineering  Laboratory, 
Naval  Construction  Battalion  Center  Controlling  office: 
Naval  Facilities  Engineering  connand 

Bail  Facilities;  Facilities,  Locations;  Alarn  Sensors; 

Alar a  Technology;  Heat  Sensors;  Heat  Detectors 
An  alarn  systea  concept  designed  to  alert  train  operators 
of  excessive  heating  of  any  of  the  wheels  of  a  fox car 
laden  with  high-explosives  has  been  developed.  The  alarn 
systea  consists  of  heat  sensors  that  are  located  on  the 
boxcar  above  each  wheel.  These  are  wired  tc  an  alarn 
transaitter  Mounted  near  the  top  of  the  boxcar. 

TN00002 
1979  03 
TM-  64-  79 
Gray,  K.  0. 

Background  and  Information  Belated  to  the  Security  Upgrade 
of  Conventional  Arns,  Anaunition,  and  Explosive  Storage 
Structures;  (41) 

Perforning  organization:  Civil  Engineering  Laboratory 
Controlling  Office:  Civil  Engineering  Laboratory 
Araories;  Facilities,  Locations;  Arsenals;  Builders 
Hardware;  Barrier  Penetratioa;  Doors;  Perineter  Barriers; 
Windows; 

Delay  Tine;  Penetration  Besistance; 

This  oeaorandun  discusses  the  probability  of 
iaplinentation  of  a  security  upgrade  of  conventional  arns 
anaunition,  and  explosive  storage  structures.  Appendices 
include:  Phys.  Sec.  BDT  and  E,  discussion  of  barrier 
philosophy,  factors  affecting  penetration  resistance, 
delay  tiae,  perimeter  barriers,  door  openings,  design 
parameters  for  door  systeas,  door  hardware. 
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SECTION  2 
KEYWORD  INDEX 

This  section  presents  the  Keyword  Index  produced  by  the  Physical 
Security  Data  Management  System.  It  consists  of  a  complete  alphabetical 
listing  of  all  keywords  currently  in  the  Data  Management  System's  controlled 
vocabulary  that  can  be  used  for  retrieval  of  bibliographical  records  in 
the  Master  List.  It  consists  of  six  pages  of  computer  output. 

Volume  II,  the  User's  Manual,  presents  detailed  instructions 

★ 

on  how  to  use  the  Keyword  Index. 


*  Ibid. 
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SECTION  3 
KEYWORD  COUNT 


3.1  OVERVIEW 

This  section  presents  the  Keyword  Count  produced  by  the  Physical 
Security  Data  Management  System.  It  is  divided  into  two  parts  as  explained 
in  the  subsections  below.  3oth  parts  consist  of  two  pages  of  computer 
output. 

3.2  KEYWORD  COUNT— VOCABULARY  WORDS 

Page  28  presents  an  alphabetical  listing  of  all  keywords  currently 

in  the  Data  Management  System.  Opposite  each  keyword  is  the  absolute  number 

of  times  the  keyword  appears  in  separate  Master  List  bibliographical  records 

followed  by  the  percentage  of  this  frequency.  Volume  II,  the  User's  Manual, 

★ 

describes  utilization  of  this  output  in  more  detail. 

3.3  KEYWORD  COUNT— DICTIONARY 

Page  29  presents  a  listing  of  all  keywords  currently  in  the  Data 

Management  System  arranged  according  to  frequency,  from  highest  to  lowest. 

Opposite  each  keyword  is  the  absolute  number  of  times  the  keyword  appears 

in  separate  Master  List  bibliographical  records  followed  by  the  percentage 

of  this  frequency.  Volume  II,  the  User's  Manual,  describes  utilization  of 

★ 

this  output  in  more  detail. 
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